In your current working directory (start in directory), probably C:\Sesame2.5 in your case.

Hammer wrote on Sep 18^th, 2009 at 2:15pm:


A little bit of experimentation shows that if I'm firing off Sesame Designer in the Program directory, the SBAS files need to be there too.  So I did that, but the problem mentioned above is still being a pain.

Thanks Mark.  Any thoughts on the @SpecCommand kookiness?

The error reads

Error while parsing module "WORKORDR (8)":
Unknown identifier.
Line 6, position 35: [Identifier: SPEC_OPERATION_LOAD]
THEN vLoadSortSpec = @SpecCommand(SPEC_OPERATION_LOAD, SPEC_TYPE_SORT ...
                      ^ 

The ^ mark points to the S in @SpecCommand (in case my formatting of the above gets fungled).

When I click on the line in the error box, my #include line is highlighted,

#include "WorkorderUsersSortSpec.sbas" 

As I said, if I take the SBAS code in its entirety and plug it directly into the app hard code (and rem out the #include statement) the Program Editor is happy dappy.

The code I'm working with is

// Loads the Dispatchers' sort spec

Var vLoadSortSpec as String

IF ( (sUserId = "Jason") OR (sUserId = "Michelle") OR (sUserId = "John") OR (sUserId = "Chris") )
THEN vLoadSortSpec = @SpecCommand(SPEC_OPERATION_LOAD, SPEC_TYPE_SORT, "Workorder # Descending") 

I have similar code in an SBAS file for my Invoice database, doing the same thing (loading sort specs) which is having the exact same problem.  Program editor is fine with all my other SBAS files (although I had to rem out the ones that hide tree items, no biggy there, I'll get to that later).

The two SBAS files are right in there with all the rest which are working, in this case in C:\Sesame2.5\Program.  I'm starting the program by double-clicking on sdesigner.exe in that directory.  But I also did as Mark suggested and hard-coded the path in the #include statement.  Same result.

Yeah, something is wonky.  However, I'll need to come back to this at another time.  For right now I'm going to hard code it so I can continue testing 2.5.  When I get closer to rollout I'll get in touch with support, see what we can figure out.  It's a fairly minor feature anyway, sorting specs for my users, and I don't see that I'll be changing it often, which is the reasoning behind tossing it into an SBAS file.

I really appreciate all your help, you guys are the best.

There's no nested #include in this file, just the code I posted above.

Scott - try something for us.

In your included file, change this
vLoadSortSpec = @SpecCommand(SPEC_OPERATION_LOAD, SPEC_TYPE_SORT, "Workorder # Descending")

to this
vLoadSortSpec = @SpecCommand(spec_operation_load, spec_type_sort, "Workorder # Descending")

and tell me if it works.

Note that all I did was make the use of the defines lowercase.

Version 2.5 includes a significant optimization to compiling when #define is in use. In the process, a piece of case-sensitivity snuck in. It's very specific and I'll surprised if it affects even six people.

In a nutshell, the use of defined constants in executable code contained in external files and then included will cause a compile error unless they are typed in all lowercase.

Infinity wrote on Sep 18^th, 2009 at 8:00pm:


That would be overkill. Instead, try to use include files for defines and only include executable code that you are using across multiple applications (in which case the defines used will need to be in lower case until we get the next release out).

Infinity wrote on Sep 18^th, 2009 at 8:17pm:


If you look in the sbasic_include.sbas file, you will see that most of the lies start with #define. This is a define. It defines something like SPEC_OPERATION_LOAD as a less human-readable value like 0. That way, you can use the define in your code, like this:
vLoadSortSpec = @SpecCommand(SPEC_OPERATION_LOAD, SPEC_TYPE_SORT, "Workorder # Descending")

You can clearly see what spec operation you are using, but Sesame sees it as 0.

The only thing affected by this issue is where you actually use the define in your executable code. The red text above indicates where this is. Nothing else will be affected by the case issue.