Home AMX User Forum NetLinx Studio

Axcess files with NS2.5

Maintaning an old legacy job I started several years ago in NS1.2 as a .pjs file.

For some reason I'm having horrible trouble with this file. It imported as an APW. The main .axs has some include lines referencing some axi files. My problem is that I can't seem to trust that the compiler is seeing the include files.

If I comment out all the include files lines and recompile the master .axs file, I get warnings saying a whole bunch of variables declared in the main .axs are not used. Fair enough I get that.

But then if I plant a deliberate error in one of the include files, save it and recompile the .axs, it doesn't find the error in the include file.

If I do a Compile System I get a ton of errors. It seems to go through each axi file compiling it, and not seeing things declared in the master .axs file, it throws errors. It compiles the .axs file last and finds no errors in that. I thought Compile System made it compile all and any .axs files you had under source code, of which one you had to tell it was the master. So why's it doing that?

Can someone explain why I'm getting this trouble?? Should I just go back to using NS1.2 and keep it as a .pjs?? My understanding that pjs and apw are just containers for these files, and doesn't affect them in any way???

Thanks

OP

Comments

  • DHawthorneDHawthorne Posts: 4,584
    Are your include files all in the same folder? Does the APW file list their properties as such? It may be the compiler isn't looking in the right place for them. The biggest problem I have ever had importing an old project is the file paths being set for the structure of the computer it was created on, not the computer I am using. My last two computers I deliberately made my project folders all use the same folder structure jsut to make such things easier.

    I don't think I have ever used includes on an Axcent job; worst case you can just paste them in place in the main program.
  • Well that's interesting what you say about being on different computers....the original job was done about 2 laptops ago.

    Yes, the include files are in the same directory. But just to be sure, I removed them from the workspace and put them back again. Same thing after I'd done that. Originally I think I started this job as one huge .axs file, then successfully broke it up into includes. I find it so much simpler dealing with shorter files, where you can handle each aspect of a system in a separate file. Do people really prefer to just work with one huge file over several smaller files? Just curious.

    Thanks

    OP
  • Include files
    Do people really prefer to just work with one huge file over several smaller files? Just curious.

    OP
    With code folding I think there is a big advantage to keep everthing in one file, especially when managing variables.

    I know others like include files, but include files are really a throw back to Axcess programming in a DOS environment where there was a 10,000 line maximum.
  • DHawthorneDHawthorne Posts: 4,584
    Well that's interesting what you say about being on different computers....the original job was done about 2 laptops ago.

    Yes, the include files are in the same directory. But just to be sure, I removed them from the workspace and put them back again. Same thing after I'd done that. Originally I think I started this job as one huge .axs file, then successfully broke it up into includes. I find it so much simpler dealing with shorter files, where you can handle each aspect of a system in a separate file. Do people really prefer to just work with one huge file over several smaller files? Just curious.

    Thanks

    OP
    Not by any means, but back in my Axcent days, I hadn't gone that direction in program layout yet, it was all one big file. Most of my Axcent work was single-room theaters anyway, and it didn't matter. Nowadays, I use modules and includes extensively.
  • yuriyuri Posts: 861
    strange question, but is your window showing the main.apw file when you press compile system? I have had some problems when i had focus on an include and then pressing compile. It then only tried to compile that file, not the project...
  • include files

    I don't agree with using one big file. I have had to work on many jobs from other people where there was one giant file, with nothing organized. You could never tell what was going where. The beauty of include files is I can see that I am just dealing with projection, conferencing etc, not all the rest of the stuff.
    Also for very large systems I make one tp include file with all the button arrays. When you have hundreds of buttons I find it much easier to just change my arrays then manage each individually.
    I guess though if you think of keeping your code organized you could do one large file.
    I am curios which way is more common. One large file, or many includes and modules?
  • setholle wrote:
    I am curios which way is more common. One large file, or many includes and modules?

    Formal computer science training will teach you to chop your code into pieces - subroutines that perform one task and fit into one page.

    But in real life if you have on giant algorithm that does one job and it's 100 pages long with no repeated code that deserves to be normalised out into another subroutine then it makes more sense to keep that together so that's what people do.

    It makes some sense to keep your subroutines in separate files grouped by function but only if

    (a) you think that way

    or

    (b) you want to be able to re-use subroutines elsewhere and have only one copy of their source file

    The latter is compelling if the code is reusable unless we are talking about the kind of amateur who just doesn't care about old jobs and lets them rot.

    I was recently forced to split my control module for a major project into one mainline and a dozen includes (all of the code being project-specific) because it was taking several seconds to save the whole 7,000 line module which was a real drag.
  • DHawthorneDHawthorne Posts: 4,584
    Because of the kludgy way NS handles includes, I wouldn't seperate out functions in an include unless they were truly project independent and reusable. ANything that's part of the project, I leave in the project code. But I will break subsytems into modules, and I will put things like shared variables and constants in includes, or settings to support a module that aren't referenced within the main code.

    These kludges I refer to are this: (1) syntax highlighting doesn't work for items in an include file; they highlight as if they were undefined, and this annoys me; (2) auto-complete also doesn't work for items defined in an include ... when you use a lot of long, descriptive names for variables, getting the spelling exactly right, or getting the right variant among several similar names, auto-complete is extremely handy; (3) include files throw off the debugging line references.

    There are probably more, that's just what I can think of before my second cup of coffee ... but I would probably use include files a lot more if not for that.

    Similarly, I already use modules extensively, but would be even more liberal with them if there was a better way to acccess private data in them than by passing a variable list as long as your arm, or relying on messages. I would love to be able to call an internal module command, for example by invoking a method, or using some manner of pointer notation, rather than needing to supply a virtual interface and send it commands through that.
  • I hope I haven't overseen this somewhere in the previous thread....

    Studio2 has a problem with Includes for AXcess environment.
    The AXcess Compiler will not consider AXIs which are linked into the workspace only but not in the same folder as the AXS. Only Includes linked by the path setting in the AXcess compiler settings are considered.

    This is reported.
  • Hi Mark

    This is interesting....I see there is a directory path seting for library and include files under the "axcess compiler" tab and the default path is to some distant location on my C drive. But when residing in the same directory, include files *are* being seen. I regularly synchronize my project files between 2 computers (every time I head out, in fact). Right now my home office desktop has the later NS2 V2.5 build 2.5.0.163, my laptop has NS2 V2.4 build 2.4.0.129. I'm now seeing that on my laptop (which is all I really care about for this job), if I make a change in an include file to create an error, save and compile, it does flag it. Do the same thing on my desktop and it does not. Very strange.....interesting thread, thanks to all for contributing....

    OP
  • I think my last post was a complete red herring. I tried the Axcess compiler settings Marc refers to and put the path to my include files, and that did work. Guess it needs a bit of help.

    OP
  • Dear Spannertech!

    That's the same issue I had upgrading my old Axcent job recently (using NS 2.5). It came out, that Axcess compiler doesn't seem to work with long dirnames. Having include files in different directory with short (8+3) name does the trick.
Sign In or Register to comment.