Need help with code

KeithJust

Would anyone out there give me a hand and comment this code to help me undersand it? Still new here!

define_function VIDsetInput(integer input, _SwtInfo SwtOuts)
{
stack_var char cmd[70]
stack_var integer i

cmd = "'VI',itoa(input),'O'"

// Loop through all zones
for (i = 1; i <= 24; i++)
{
if (SwtOuts.vid_out)
{
cmd = "cmd,itoa(i),','"
}
}

KeithJust

Guys or for that matter has anyone ever setup a DXP program with a component video device?

NMarkRoberts

define_constant

nOutputCount = 24

(* Build a matrix switcher command *)
define_function VideoSetInput(
  integer nInput, (* Which input to switch *)
  tSwitchInfo SwitchOutputs) (* Structure containing array of flags indicating which outputs to switch on *)
{
stack_var char sCommand[70]
stack_var integer nOutput
    
sCommand= "'VI',itoa(nInput),'O'"
    
(* Loop through all outputs on the switcher *)
for (nOutput= 1; nOutput<= nOutputCount; nOutput++)
  {
  (* Is this output meant to be switched on? *)
  if (SwitchOutputs.bVideoOut[nOutput])
    {
    (* Add another output to the command *)
    sCommand = "sCommand,itoa(nOutput),','"
    }
  }
}

The code has a number of oddities:

(* Oops (a) It uses stack_var where it ought to use local_var Edited *)

(b) It takes no account of switching off outputs - maybe that's implicit in the command protocol

(c) The tSwitchInfo structure presumably contains nothing else, in which case it ought not be a structure

Joe Hebert

NMarkRoberts wrote:

The code has a number of oddities: (a) It uses stack_var where it ought to use local_var

Why should it use a local_var?

NMarkRoberts wrote:

The tSwitchInfo structure presumably contains nothing else, in which case it ought not be a structure

Why can?t it be a struct? Different strokes for different folks. A struct with one member is perfectly legal and also allows other members to be added easily. And who?s to say it contains nothing else as the definition isn?t posted? It?s possible the struct contains things like volume level, mute, bass level, etc.

I see nothing odd about the code at all. It may not be the way you or I would approach it but I wouldn?t take away anything from the person who wrote it.

NMarkRoberts

Joe Hebert wrote:

Why should it use a local_var?

Oops:

Its usage is local_var not stack_var - a stack_var is persistent across calls, it seems to me that you should only declare as stack_var when you intend to make use of that. I'm not suggesting the code as it stands is faulty - just that clarity is better served by using local_var, and a stack_var is a bug waiting to happen unless you explicitly want what it gives you.

Edit:

Its usage is stack_var not local_var - a local_var is persistent across calls, it seems to me that you should only declare as local_var when you intend to make use of that. I'm not suggesting the code as it stands is faulty - just that clarity is better served by using stack_var, and a local_var is a bug waiting to happen unless you explicitly want what it gives you.

Joe Hebert

NMarkRoberts wrote:

a stack_var is persistent across calls, it seems to me that you should only declare as stack_var when you intend to make use of that. I'm not suggesting the code as it stands is faulty - just that clarity is better served by using local_var, and a stack_var is a bug waiting to happen unless you explicitly want what it gives you.

Nope, it's the other way around. A local_var is persistent across calls, a stack_var is re-initialized every time.

KeithJust

Anyone somewhat familier with DXP for quick Sunday sidejob?

Guys hope it's OK to post this here. Anyone somewhat familier with DXP that can help me with some code? What I have is a DXP generated program (that only allows adding composite video sources) and would like to modify the code to allow me to add component video sources. Can pay anyone willing to work on project today with Paypal. Again guys hope it's OK to post this here but I sure could use some help. Email me at keithjust@hotmail.com if interested. Thanks again.

NMarkRoberts

Oops

Joe Hebert wrote:

Nope, it's the other way around. A local_var is persistent across calls, a stack_var is re-initialized every time.

Argh. Thanks Joe. In my current project there are 658 stack_vars and 0 local_vars.

I'll just go and have a lie-down.

vining

NMarkRoberts

In my current project there are 658 stack_vars and 0 local_vars.
I'll just go and have a lie-down.

Having all stacks is the ideal situation so why be bummed out? Your code must be working otherwise you would have realized your vars weren't retaining values when you were expecting them to.

NMarkRoberts

vining wrote:

NMarkRoberts

Having all stacks is the ideal situation so why be bummed out? Your code must be working otherwise you would have realized your vars weren't retaining values when you were expecting them to.

I always use stack_vars, this is good - when I wrote the post that Joe corrected my brain must have been on holiday.

Joe Hebert

NMarkRoberts wrote:

Argh. Thanks Joe. In my current project there are 658 stack_vars and 0 local_vars.

I'll just go and have a lie-down.

No worries, mate.

DHawthorne

It is not a bad thing at all to use stack_var liberally or by habit, except when it absolutely must retain value between calls. There is far more volatile memory in a master than non-volatile; if you have a big project and declare it all local_var, you are eating it up for no reason, and killing processor ticks if you have to initialize it to boot.