Structure References

DanRessler

I was just about to post a long list of code for timeline help, when I tried one last thing ... and of course it worked (at which point I taught my 3100 a whole new set of "special commands" that my wife won't let me use at home). You see, I have created a structure to store all things relative to a communication queue:

DEFINE_TYPE

STRUCTURE CommunicationQueue232
{
CHAR MessageQueue[10][15]
INTEGER WaitingForResponse
INTEGER LastMessagePointer
INTEGER QueueLength
LONG TimeLineID
}

... and then created a structure for each queue:

DEFINE_VARIABLE

CommunicationQueue232 Sony232


I was assigning the timeline ID in start, since I can't assign them in the variable section, with code such as:

Sony232.TimeLineID = 1


I was going crazy trying to create a timeline using that ID, because nothing was ever firing. However, when I created a LONG contstant:

LONG SonyTLID = 1

... and used that in my TIMELINE_CREATE statement (and in the TIMELINE_EVENT), it all worked fine.

*********************************************************************

So my question is, am I missing something? I thought that Netlinx could dereference (OK, it's not a pointer, but not sure of a better verb) a structure in functions and events as long as the component part was defined correctly (as LONG in this case). Is this a bug, an unintended feature, or something I'm missing? It's not a big deal, but I was going to try to functionalize some of my 232 logic into a module and liked the idea of having a structure to keep the relevant stuff together.

Dan

mpullin

DanRessler wrote:

I was just about to post a long list of code for timeline help, when I tried one last thing ... and of course it worked (at which point I taught my 3100 a whole new set of "special commands" that my wife won't let me use at home).

lol

DanRessler wrote:

So my question is, am I missing something?

In a word, yes. From the NetLinx Keyword help:

When creating a TIMELINE_EVENT, the timeline ID must be a user defined long constant.

The NetLinx compiler will not semantic check the type of the timeline ID, and the NetLinx runtime system will attempt to cast the contents of the timeline ID constant, to a long constant. A runtime error will occur if the cast is unsuccessful.

I never use timelines, they are too unintuitive IMHO. I always have a bunch of waits in my DEFINE_PROGRAM for processes I want to run every N seconds.

vining

mpullin wrote:
I never use timelines, they are too unintuitive IMHO.

Wow, I love timelines and think they're darn clever, but then again I'm a #2 style code writer while it appears every one else are #1s.

I don't know of any other way to make a variable hold n repeat. Hold a button and increment slowly and after x amount of seconds increment fast. I don't even understand their full potential yet but I'll admit I am a little simple that way.

mpullin

vining wrote:

Wow, I love timelines and think they're darn clever, but then again I'm a #2 style code writer while it appears every one else are #1s.

I don't know of any other way to make a variable hold n repeat. Hold a button and increment slowly and after x amount of seconds increment fast. I don't even understand their full potential yet but I'll admit I am a little simple that way.

To be fair, I come from a computer programming background and NL timelines don't represent any classical data structure so that could have something to do with why I can't stand them.

Your changed rate of holding & repeating can be accomplished via HOLDTIME btw.

BUTTON_EVENT[arrTP,butBUTTON]{
    PUSH: PULSE[dvDEVICE,1]
    HOLD[5,REPEAT]: if(BUTTON.HOLDTIME % 10 == 0 || BUTTON.HOLDTIME > 50) PULSE[dvDEVICE,1]
}

This code will pulse every second until 5 seconds have passed, then it will pulse twice a second.

DanRessler

mpullin wrote:

When creating a TIMELINE_EVENT, the timeline ID must be a user defined long constant.

Doh! I must have read that line thirty times, and the word "constant" slid past my eyes every time. It's still a shame that I can't put it all in a structure to keep it nice and clean, but I'm sure I'll survive.

Thanks!

Dan

vining

mpullin wrote:
Your changed rate of holding & repeating can be accomplished via HOLDTIME btw.

BUTTON_EVENT[arrTP,butBUTTON]{
    PUSH: PULSE[dvDEVICE,1]
    HOLD[5,REPEAT]: if(BUTTON.HOLDTIME % 10 == 0 || BUTTON.HOLDTIME > 50) PULSE[dvDEVICE,1]
}

This code will pulse every second until 5 seconds have passed, then it will pulse twice a second.

BUTTON.HOLDTIME, that's one of those obscure Button_Event Data objects that I'm sure I seen before in a list but never imagined a use for it. Your method also support any number of repeat rates if needed. I must admit it took me a couple minutes to figure out how it works and I'll also admit it's a much simpler and elegant way to do a variable hold and repeat than a timeline.

Sometimes I think my brain takes the long route just for the exercise!

DHawthorne

Interesting - I've never run into this particular issue (and I use timelines extensively) because I have always defined my timeline IDs in DEFINE_CONSTANT. It's how they were introduced to me, and I never thought to do it differently.

DanRessler

Well, it's absolutely clear now that it has been pointed out to me. Defining the timeline ID in constants isn't a big deal. I just got very comfortable in a past life using structures to group like information, and was coding without referencing.

Dan

mpullin

Yeah Dan, it would be nice to be able to group like information, but think of it this way: since it's bad for two timelines to have the same ID, it makes more sense to group the timeline IDs together to make sure there's no double assignments.

I suppose you could declare the timeline IDs in an array and give each of your objects an integer that represents which slot in the timeline array that object's timeline is in... but we've already established that OOP principles aren't going to work here so let's stop trying to fake it

DanRessler

mpullin wrote:

Yeah Dan, it would be nice to be able to group like information, but think of it this way: since it's bad for two timelines to have the same ID, it makes more sense to group the timeline IDs together to make sure there's no double assignments.

I suppose you could declare the timeline IDs in an array and give each of your objects an integer that represents which slot in the timeline array that object's timeline is in... but we've already established that OOP principles aren't going to work here so let's stop trying to fake it

That is an excellent point!