Axcess files with NS2.5
Spannertech
Posts: 53
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
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
0
Comments
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.
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
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.
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?
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.
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.
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.
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
OP
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.