error 200 after !loadmodulefile

[Jim Locker]

I am loading a module this way: if fileexists(filename = “accounts.sml”) e = 0: !loadmodulefile(“accounts.sml”,error = e) if e != 0 // do some error processing things else ActVer(sg) end if else // do some error processing things end if The module accounts.sml contains the following code, compiled to be a library: function ActVer(system_globals sg) export sg.ActVer = “2.0.0.devel” end function where the type system_globals is included and is valid On compile, I get a warning about ActVer not being defined. This is understandable, but annoying; I would love to be able to suppress that warning. When I try to execute the line ActVer(sg) I am getting error 200, which informs me that I am trying to take the value of an object that has no value. If I directly include the module accounts.smu into my main project, it works fine, of course. Why am I getting this error?

[Jim Locker]

When I change the code to this:

if fileexists(filename = "accounts.sml")
e = 0: !loadmodulefile("accounts.sml",error = e)
if e != 0
// do some error processing things
else
sg.ActVer = ActVer()
end if
else
// do some error processing things
end if

and…

function ActVer(system_globals sg) information "[simpol::return::string]
export
end function "2.0.0.devel"

Then it works.

This means that my type reference is not getting passed correctly. This
potentially is a very serious problem for me with massive design
implications. Can I, or can I not, pass references to my own types into
libraries that I construct? If so, how?

[Jim Locker]

I did figure this out.

In my library module, when I first compiled it, I got a warning about
undefined reference to system_globals sg.

So, I included the file that contains that definition as an include, which
eliminated the warning.

Apparently, this creates a local copy of that type rather than just
providing a reference to the definition. So, when I passed a reference to
the function, something got confused and my reference that was passed was
not picked up. Or something.

Anyway, removing the include from the accounts file, and exporting the
reference from the main file (which loads the accounts file) solved the
problem; the accounts library can now access the system_globals type which
is what I need.

However, this now means that whenever I compile the accounts library file,
I am going to get at least hundreds of warnings about an undefined type;
the system_globals type contains state variables that define version,
features, user options, currently employed options and settings, and in
fact any information that needs to be globally available to this program,
and EVERYBODY reads it to find out what to do.

The accounts section will also have its own globals type that will contain
all information that is particularly needed by all of the accounting
section. The code for the accounting section will run close to 10,000
lines when I have translated it all, and if I have hundreds of spurious
warnings about undefined types, it is going to make debugging a royal PITA.

Accounts is an optional module that does double-entry bookkeeping and
comes with some versions of the program and not with others (there is an
alternate accounts module that is cash flow (single entry only) which
comes with those versions that don't do double-entry) so I want it in a
separate library; I provide it only with those versions that use it.

I guess I'll have to keep my include that defines that type, and compile
with that include included until I have gotten rid of the genuine typos
and errors that result in undefined types, then compile again with that
include commented out in order to actually use the library.

[Michael]

Jim wrote:
> However, this now means that whenever I compile the accounts library
> file, I am going to get at least hundreds of warnings about an
> undefined type; the system_globals type contains state variables that
> define version, features, user options, currently employed options
> and settings, and in fact any information that needs to be globally
> available to this program, and EVERYBODY reads it to find out what to
> do.
>
> The accounts section will also have its own globals type that will
> contain all information that is particularly needed by all of the
> accounting section. The code for the accounting section will run
> close to 10,000 lines when I have translated it all, and if I have
> hundreds of spurious warnings about undefined types, it is going to
> make debugging a royal PITA.

I have to say, I haven't run into this, but that is because I haven't
heavily used the !loadmodule() capability. The reason for that is I
don't see much point in it, if I can't unload the module. If I am going
to load it anyway, I might as well link it in as an included library.
The only real use I make of !loadmodule() is to load something external
at runtime, that might not need to be loaded.

As for the wrnings, if you can reduce the number of places this is
included, you can substitute type(*) for it. Another very nifty trick is
to create a sort of base type, typetag it, then use one of a separate
type name that is just like it or maybe the same with extensions, and
typetag it with the same tag as well. Sort of like this:

Put this one in the main program:

type foo(foo) export
embed
string name
integer id
end type

Put this one in the module you will load

type dfoo(foo) export
embed
string name
integer id
boolean ready
end type

Now in your code use:

type(foo) varname

and assign it the items that are of type dfoo. In the IDE it won;t
complain during compile, and it will also do intellisense-like stuff
that matches the definition of type foo.

You can also make a complex one with all the methods, but leave the
methods empty, and just use the tagged version (treat it like a real
base class with virtual methods).

Ciao, Neil

[Jim Locker]

Alright, I will try that.

Actually, the loadmodule feature is VERY handy. I made extensive use of
it in SBL and will be making extensive use of it in Simpol. That I can't
unload the module really doesn't matter to me.

Using loadmodule, I can build and fully link a basic version of my
program, that will run just fine by itself. But I can then provide
optional features quite easily without recompiling and relinking. I
therefore do not need to have lots of different flavors of executable
around.

Specifically, my package does property management. Some people want the
software to handle depreciation/amortization; others don't. So
depreciation/amortization is a separate module; if you don't want it, you
don't have to pay for it and I don't have to support code that has that
feature in it. If you want it, I'll provide it and set a flag in a config
file that says you are allowed to use it, so your basic program will
search for the module and load it if it finds it.

The basic code is smart; whenever it might need to invoke
depreciation/amortization code, it will check first to make sure that
module is available and loaded, and if so it will invoke the relevant
code. If not, it won't.

I do this with budgeting, purchase orders, the accounting system,
depreciation amortization, PPCS, credit card processing, and a
customizable "personality" module – which reconfigures the entire program
through strategically located calls to specific functions to make it more
appropriate for specific jobs such as homeowner associations, motels, and
trailer parks.

This makes code maintenance a LOT easier, provides me a capability to "mix
and match" components without having to ship an executable that can do
everything but has features turned off, and makes it easier to support
because, since for THIS version THAT code simply isn't shipped, I don't
have any issues associated with supporting THAT code in case something is
not working right.

I actually have three variants of the accounting system. The basic
cash-flow version is built into the basic program. There is a
checkwriting extension for the cash flow version which is a plug-in module
provided separately. There is also a complete double entry system with
extensive bank account support, trial balance, and general ledger which is
a different plug in module. It is very cool, and by setting one config
file correctly, I tell the program what it is and what it is allowed to
do. It then loads the appropriate modules, or falls back to a safe
configuration of those modules are not found.

I really did stretch SBL to its absolute limits. The product hasn't done
real well in the marketplace, mostly I think because of limitations
imposed on me by the old-fashioned-looking GUI in superbase, and by the
existence of old 16 bit code that had to deal with Microsoft's rather
buggy 16 bit subsystem. Simpol's multi-threaded architecture, ability to
run on 64 bit, multi-platform ability, and use of wxwidgets – which really
opens up the interface possibilities – is going to make a big difference.
I am going to hire a form designer to create a really nice user interface
design (I am not artistic; my designs are highly functional but not
pretty).

I'm also separating the database from the GUI internally, which will make
it a lot easier to deploy different GUIs for the web or for cellphones,
and will also make it easy to deploy an SQL version of this thing for
those clients that just have to have SQL. All it will take is a different
database plugin.

Oh, yes. I really like the loadmodule capability.

[Michael]

Jim wrote:
> Alright, I will try that.
>
> Actually, the loadmodule feature is VERY handy. I made extensive use
> of it in SBL and will be making extensive use of it in Simpol. That
> I can't unload the module really doesn't matter to me.
>
> <snip>
>
> I really did stretch SBL to its absolute limits. The product hasn't
> done real well in the marketplace, mostly I think because of
> limitations imposed on me by the old-fashioned-looking GUI in
> superbase, and by the existence of old 16 bit code that had to deal
> with Microsoft's rather buggy 16 bit subsystem. Simpol's
> multi-threaded architecture, ability to run on 64 bit, multi-platform
> ability, and use of wxwidgets – which really opens up the interface
> possibilities – is going to make a big difference. I am going to hire
> a form designer to create a really nice user interface design (I am
> not artistic; my designs are highly functional but not pretty).
>
> I'm also separating the database from the GUI internally, which will
> make it a lot easier to deploy different GUIs for the web or for
> cellphones, and will also make it easy to deploy an SQL version of
> this thing for those clients that just have to have SQL. All it will
> take is a different database plugin.
>
> Oh, yes. I really like the loadmodule capability.

Sounds very impressive. I hope that it does well. I am glad you like the
!loadmodule() stuff. Used correctly it has a lot of potential, as you
described.

Ciao, Neil

[Author]

Posts