Things that make me go "HMMMM!" :)
Spire_Jeff
Formerly Caffeinated Programmer
Ok, using this function:
Just a question I have, but I don't have time to play with it right now, so I decided to throw it out there for the masses to play with
Jeff
DEFINE_FUNCTION integer[MAX_NUM_DEVS] filterArray(integer type){
stack_var integer arrayX[MAX_NUM_DEVS];
stack_var integer x;
switch (type){
case 1:{ // nUSER_BTN_TEST3
for(x=1;x<=LENGTH_ARRAY(nUSER_BTN_TEST3);x++)
arrayX[x] = nUSER_BTN_TEST3[x];
return arrayX;
}
}
}
Does the stack_var that I am returning continue to exist after the function exits? If so, when does it finally clear itself from memory? Am I opening a path to memory leaks by doing this? This function is intended to be used to supply information to another function, so there are pointers flying all over the place... does NetLinx have an ATC (Air Traffic Controller) to deal with all of this elegantly?Just a question I have, but I don't have time to play with it right now, so I decided to throw it out there for the masses to play with
Jeff
Comments
-
I think it's like a relay race where you're just passing the baton and it only exists in the hand of the current holder.
-
At first glance at the topic name, I was scared to look.

I agree with Vining here, BTW. -
I think it's more like a game of smear the queer... Remember that game as kids? One person picks up the ball and runs for their life, while the other kids book it after them while trying to keep up speed as to really hit them hard when the opportunity arises. Once the kid with the ball has been "taken care of" some other kid, for no understandably motivational reason, picks up the ball in hopes of meeting the same fate and runs for his little life.
Like I said, I think it's more like Smear the Queer. -
Hmmmmm....jason_the_adams wrote: »I think it's more like a game of smear the queer... Remember that game as kids? One person picks up the ball and runs for their life, while the other kids book it after them while trying to keep up speed as to really hit them hard when the opportunity arises. Once the kid with the ball has been "taken care of" some other kid, for no understandably motivational reason, picks up the ball in hopes of meeting the same fate and runs for his little life.
Like I said, I think it's more like Smear the Queer. -
Well, that is the way I thought it happened, but I was having an odd problem with this and changing from stack_var to local_var seems to have cleared up the issue.... When I have some more time, I will try to narrow down the cause of the problem.
Jeff
P.S.
In case anyone is wondering about the situation, I have a function being called that creates a stack_var of type integer[]. There is a switch case that calls another function using the integer[] with different options based on the case. (a couple other things happen inside the case as well, but nothing tied to the integer[].) When the first case is used, the array passed is correct. When the second case is used, the array that was getting passed was not initialized. Right now there are only 2 different cases. -
SET_LENGHT_ARRAY
When ever I make an assignment like:
nSomeArray[x] = x
or
nSomeArray[x] = nSomeOtherArray[x]
I always call the function SET_LENGTH_ARRAY()
In your for loop try adding
for(x=1;x<=LENGTH_ARRAY(nUSER_BTN_TEST3);x++)
{
arrayX[x] = nUSER_BTN_TEST3[x];
SET_LENGTH_ARRAY(arrayX,x);
}
Dan -
I don't think the length is the problem. As I recall, the array was being set correctly, then when it was passed from the second case, the values all changed to random numbers (basically it created a new instance of the stack_var). Eventually, I will try to get the code stripped down to only the two functions and necessary code to test it out. I will try to post the results here.
Jeff -
Any properly executed function handler should allocate memory for its return value independent of any stack variable within the module that might be assigned to it. Once you execute the RETURN statement, that stack variable referenced by all rights should get assigned to the memory allocated to the return value. I would be very surprised if this were not the case in NetLinx. So, in other words, your return value should still be intact until next time you call the function.
-
I've been working on a recursive funtcion that has uses a wait before it calls itself and I was passing it a constant value and then out of curiosity I decided to see what would happen if I passed it a var value that was declared as a STACK in the code that initially calls this function.
I thought it would still work but I'm never quite sure of any thing lately. Sure enough the function holds and retains the value and changes to the initial value through out all the waits.The code: DEFINE_FUNCTION fnDoRadarUpdate(INTEGER iRadarIndx) { SEND_COMMAND dvActiveTP,"'^RMF-Ani_Rad_',itoa(iRadarIndx -1),',%Aridge/lite/', Rad_Image_Type[nGetRadImageIndx],'%F',cGetRadRegion,'_',itoa(iRadarIndx - 1),'.png'" ; SEND_COMMAND dvActiveTP,"'^RFRP-Ani_Rad_',itoa(iRadarIndx - 1 )" ; SEND_LEVEL dvActiveTP, 1, iRadarIndx ; SEND_COMMAND dvActiveTP,"'^BMP-1,',itoa(iRadarIndx),',Ani_Rad_',itoa(iRadarIndx - 1)" ; SEND_COMMAND dvActiveTP,"'^RFR-Ani_Rad_',itoa(iRadarIndx - 1)" ; if(iRadarIndx > 1) { WAIT 5 { fnDoRadarUpdate(iRadarIndx - 1) } } else { RETURN ; } } DEFINE_FUNCTION fnChangeRadImageType() { STACK_VAR INTEGER nRadarIndx ; nRadarIndx = NUM_ANI_RAD_PICS ; //NUM_ANI_RAD_PICS = 8 fnDoRadarUpdate(nRadarIndx) ; }Notifications: Line 12 :: Command To [10001:28:1]-[^RMF-Ani_Rad_7,%Aridge/lite/N1P%FOKX_7.png] - 11:37:34 Line 13 :: Command To [10001:28:1]-[^RFRP-Ani_Rad_7] - 11:37:34 Line 14 :: Level Value To [10001:28:1] - Level 1 Value= 8 - 11:37:34 Line 15 :: Command To [10001:28:1]-[^BMP-1,8,Ani_Rad_7] - 11:37:34 Line 16 :: Command To [10001:28:1]-[^RFR-Ani_Rad_7] - 11:37:34 Line 17 :: Feedback:On [10001:28:1] - Channel 64 - 11:37:34 Line 18 :: Output Channel:On - From [10001:28:1] - Channel 64 - 11:37:34 Line 19 :: Feedback:Off [10001:28:1] - Channel 67 - 11:37:34 Line 20 :: Output Channel:Off - From [10001:28:1] - Channel 67 - 11:37:34 Line 21 :: Command To [10001:28:1]-[^RMF-Ani_Rad_6,%Aridge/lite/N1P%FOKX_6.png] - 11:37:34 Line 22 :: Command To [10001:28:1]-[^RFRP-Ani_Rad_6] - 11:37:34 Line 23 :: Level Value To [10001:28:1] - Level 1 Value= 7 - 11:37:34 Line 24 :: Command To [10001:28:1]-[^BMP-1,7,Ani_Rad_6] - 11:37:34 Line 25 :: Command To [10001:28:1]-[^RFR-Ani_Rad_6] - 11:37:34 Line 26 :: Command To [10001:28:1]-[^RMF-Ani_Rad_5,%Aridge/lite/N1P%FOKX_5.png] - 11:37:35 Line 27 :: Command To [10001:28:1]-[^RFRP-Ani_Rad_5] - 11:37:35 Line 28 :: Level Value To [10001:28:1] - Level 1 Value= 6 - 11:37:35 Line 29 :: Command To [10001:28:1]-[^BMP-1,6,Ani_Rad_5] - 11:37:35 Line 30 :: Command To [10001:28:1]-[^RFR-Ani_Rad_5] - 11:37:35 Line 31 :: Command To [10001:28:1]-[^RMF-Ani_Rad_4,%Aridge/lite/N1P%FOKX_4.png] - 11:37:35 Line 32 :: Command To [10001:28:1]-[^RFRP-Ani_Rad_4] - 11:37:35 Line 33 :: Level Value To [10001:28:1] - Level 1 Value= 5 - 11:37:35 Line 34 :: Command To [10001:28:1]-[^BMP-1,5,Ani_Rad_4] - 11:37:35 Line 35 :: Command To [10001:28:1]-[^RFR-Ani_Rad_4] - 11:37:35 Line 36 :: Command To [10001:28:1]-[^RMF-Ani_Rad_3,%Aridge/lite/N1P%FOKX_3.png] - 11:37:36 Line 37 :: Command To [10001:28:1]-[^RFRP-Ani_Rad_3] - 11:37:36 Line 38 :: Level Value To [10001:28:1] - Level 1 Value= 4 - 11:37:36 Line 39 :: Command To [10001:28:1]-[^BMP-1,4,Ani_Rad_3] - 11:37:36 Line 40 :: Command To [10001:28:1]-[^RFR-Ani_Rad_3] - 11:37:36 Line 41 :: Command To [10001:28:1]-[^RMF-Ani_Rad_2,%Aridge/lite/N1P%FOKX_2.png] - 11:37:36 Line 42 :: Command To [10001:28:1]-[^RFRP-Ani_Rad_2] - 11:37:36 Line 43 :: Level Value To [10001:28:1] - Level 1 Value= 3 - 11:37:36 Line 44 :: Command To [10001:28:1]-[^BMP-1,3,Ani_Rad_2] - 11:37:36 Line 45 :: Command To [10001:28:1]-[^RFR-Ani_Rad_2] - 11:37:36 Line 46 :: Command To [10001:28:1]-[^RMF-Ani_Rad_1,%Aridge/lite/N1P%FOKX_1.png] - 11:37:37 Line 47 :: Command To [10001:28:1]-[^RFRP-Ani_Rad_1] - 11:37:37 Line 48 :: Level Value To [10001:28:1] - Level 1 Value= 2 - 11:37:37 Line 49 :: Command To [10001:28:1]-[^BMP-1,2,Ani_Rad_1] - 11:37:37 Line 50 :: Command To [10001:28:1]-[^RFR-Ani_Rad_1] - 11:37:37 Line 51 :: Command To [10001:28:1]-[^RMF-Ani_Rad_0,%Aridge/lite/N1P%FOKX_0.png] - 11:37:37 Line 52 :: Command To [10001:28:1]-[^RFRP-Ani_Rad_0] - 11:37:37 Line 53 :: Level Value To [10001:28:1] - Level 1 Value= 1 - 11:37:37 Line 54 :: Command To [10001:28:1]-[^BMP-1,1,Ani_Rad_0] - 11:37:37 Line 55 :: Command To [10001:28:1]-[^RFR-Ani_Rad_0] - 11:37:37
-
this is strangely familiar...jason_the_adams wrote: »I think it's more like a game of smear the queer... Remember that game as kids? One person picks up the ball and runs for their life, while the other kids book it after them while trying to keep up speed as to really hit them hard when the opportunity arises. Once the kid with the ball has been "taken care of" some other kid, for no understandably motivational reason, picks up the ball in hopes of meeting the same fate and runs for his little life.
Jason... what you've described is called AFL.... -
AFL
GAHAHAHAHAHAHAHahahahhaa *cough* hah!
Categories
- All Categories
- 2.5K AMX General Discussion
- 922 AMX Technical Discussion
- 514 AMX Hardware
- 502 AMX Control Products
- 3 AMX Video Distribution Products
- 9 AMX Networked AV (SVSI) Products
- AMX Workspace & Collaboration Products
- 3.4K AMX Software
- 151 AMX Resource Management Suite Software
- 386 AMX Design Tools
- 2.4K NetLinx Studio
- 135 Duet/Cafe Duet
- 248 NetLinx Modules & Duet Modules
- 57 AMX RPM Forum
- 228 MODPEDIA - The Public Repository of Modules for Everyone
- 943 AMX Specialty Forums
- 2.6K AMXForums Archive
- 2.6K AMXForums Archive Threads
- 1.5K AMX Hardware
- 432 AMX Applications and Solutions
- 249 Residential Forum
- 182 Tips and Tricks
- 146 AMX Website/Forums

