Checking if a device from an array, equals a certain device
Jorde_V
Posts: 393
I'm trying to do the following:
however it won't let me compile and only gives me syntax error. Is there a different way to check this?
define_variable dev touchpanels[]={tp_5200,tp_ipad}; integer navigation[]={ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 } define_event button_event{ PUSH:{ page_flip(touchpanels[get_last(touchpanels)], get_last(navigation)); } } define_function page_flip(dev tp, integer navigation) { if(tp == touchpanels[1]){ ; } else if(tp == touchpanels[2]){ ; } }
however it won't let me compile and only gives me syntax error. Is there a different way to check this?
0
Comments
Happens to the best of us!
AMX support told me it wasn't possible though..
Glad it's solved now though.
Jjames, you trying to exclude me there?
You can definitely do what I think you want to do which is just see what tp in the array fired the button and then do something depending on which one it was. Personally I wouldn't pass the dev I'd just pass the index number but either way will work.
They told me it wasn't possible to check whether a device equals the device in an array using the method I described above. Works just fine now, though I do wonder why it started working after I restarted NS.
What would be the benefit of passing the index number rather than use the actual dev?
Here's the code using index instead. Just a little different.
eventually you'll have other arrays that work with your UI array that will tell you what type device it is (iPad, MVP9000i, MET-Ecom, KP, etc..) another to tell you the resolution, another for online status, etc. Using the index numbers is the easiest way sort this out and keep your code flexible so it's a good habit to get into so that you'll have less re-writing to do down the road when you need these other arrays or the next job when you have to re-use this code and the iPad isn't the 2nd device in the UI array.
The hardest part about writing code is trying to make it re-usable with out going through it line by line to make changes for every job. The idea is to change some initial definitions and quantities and the rest of the code should take care of itself.
I don't see any advantage except for visually seeing what you're comparing.
And also - unless I'm totally missing something (it is 3:30 am), comparing a dev to an indexed dev array works just fine.
Line 1 (03:36:50.612):: Device was dvIPAD_1
Line 2 (03:36:50.614):: Device was dvIPAD_1
Line 3 (03:36:54.341):: Device was dvIPAD_2
Line 4 (03:36:54.342):: Device was dvIPAD_2
Both examples in the function worked just fine.
I'm doing the same thing as you are and have been working on it for the past few jobs now. I now work with structures rather than arrays, and try to make things as OO as possible. Using a lot of pre-compiler directives as well. Makes things easier to manage.
I used that method for a while but noticed that using structures slowed any stuctures processing down by a larger than expected margin. As well, since they can't be passed to functions or modules, I went back to using mostly arrays.
Paul
Do you have any evidence that using structures slows down processing by a larger than expected margin? I’ve never ran into any issues that would be attributed to that and I use structures everywhere.
Structures can be passed directly into functions and you can also declare a structure instance inside a function same as you would an integer or any other intrinsic data type.
I use structures all the time as I find the code much easier to read, write, organize and maintain vs. using a whole bunch of multi-dimensional arrays.
To each their own....
Sorry, I meant modules not functions. They can be used in functions like you mention, I just don't do that typically since I went back to mostly arrays. I didn't find much of a performance issue with simple structs, but when I was trying to design my code to be more OO I used nested structs, and this is where I really noticed a difference. I didn't do any formal testing, but I was doing some bulk copying from one nested struct to another, and then sending the result to a list on a touch panel. I was using the nested struct method and found a lot of latency I couldn't account for. After trying all manner of things to get rid of it, I switched from nested structs to arrays and all of a sudden the latency disappeared. It appeared again switching back to nested structs. I would prefer to use nested structs but for this reason I now only use simple structs and only for storage and not for processing. I couldn't figure out why the nested structs were so slow, but arrays work just as well and have the advantage that I can pass them to modules. I prefer multidimensional array notation to struct notation anyway since I don't need to type the name of the struct member, just the array index, and the code completion in NS Studio doesn't seem to work all that well for struct members which is annoying.
Paul
How were you doing the copying? Did you copy each member of one struct to each member of another struct or did set one struct equal to another with one line of code?
For example let’s say we have a struct that contains info for a song and we have a nested struct for an album that contains info for an album along an array of 12 songs structs:
We declare a single album and then a collection of albums
If we wanted to take a single album and copy it as the first album in the collection we could take the long route and copy each member like this:
Or we can take the single line approach to accomplish the same thing like this:
Or if we wanted to get an editable copy of the 5th album in the collection we need one line of code:
And let’s say we want to prompt the user if he tries to exit before saving the changes but we only want to prompt if the editable copy is different than the saved copy. Unfortunately we can‘t do that with one line of code since we can’t perform Boolean operators on structs. Instead we have to compare each member of one to another.
I prefer dot notation myself, it’s easier for my brain to process.
Incredibly annoying, exacerbating. It really takes the fun out of using structs.
Yes one would hope.
Both. You might not see much latency with a small structure like in your example. However, with structs like this one, where a number of members can have a kilobyte or more of storage, and there are nested structs (since removed), things start to bog quite quickly. Fortunately arrays don't seem to exhibit this symptom. I can only guess that the memory management system isn't nearly as efficient with structs as it is with arrays.
It was only the nested structs that seem to cause the issue. I didn't have time to do more testing so I could be off. But with arrays the compiler can do some optimizations, whereas with nested structs, perhaps due to the padding involved, it may not be able to do this. Just a guess.
Paul