jjames wrote: »
I could have swore that it populates the system number of the workspace.
matt95gsr wrote: »
I have used it, and do from time to time still use it - but not often enough to warrant keeping it around.
Jimweir192 wrote: »
Surely the simple answer to this (and similar issues with software / firmware) would be to have a protected area on amx.com where certified programmers can access:
Previous key version of software - i.e. older NS2 with support for PJS file types, previous couple of versions of the main apps in case of bugs in new releases.
Legacy Firmware versions - for when we have to update old installs...
I know all these things can be obtained from TS on request - but it is always outside of office hours when your backs against the wall and you need these things...
Thats what I'd like to see...
Doug Hall wrote: »
We will be rolling a new archive out on our website before the end of this year. We think that this will be greatly beneficial in supporting legacy systems while cleaning up the current application pages.
Colzie wrote: »
You can have multiple define_device, define_vars, etc., anywhere in your code. How would super_include know which section to put the include contents into? I guess it could use the first appropriate section in the Master file?
dvSomeDevice1 = 5001:1:1
dvAnotherDevice1 = 5001:2:1
VOLATILE INTEGER nVar1
DEFINE_VARIABLE//INCLUDE CALLS GO BELOW
#INCLUDE 'Misc Functions.axi'
#INCLUDE 'Dev 1 Include File.axi'
#INCLUDE 'Dev 2 Include File.axi'
Jeff wrote: »
Are there any situations where a single pass compiler functioning as it currently does would be preferential to a multi pass compiler like DHawthorne described? It seems to me that multiple passes>a single pass at all times, but maybe I'm missing something.
Is there any particular reason that you might want a define variable section to not compile until after some random define event section?
chill wrote: »
I know I've posted this request before - possibly in this very thread, though I'm too lazy to read all 14(!) pages to find out.
In device notifications, it would be a huge benefit to be able to see strings to and from IP sockets, i.e. the 0:x:0 devices that have an ip_[client|server]_open associated with them. Of course there are workarounds, but it would help with troubleshooting and debugging if they worked like any other device.
yuri wrote: »
isn't that gonna happen in NS3?