Feature Request(s) for next DOS version.

[Michael Mattias]

As long as I can recall, Mike, you've had some "monster" application you maintain where limitations on parameter counts and UDT sizes have become in fact real limitations on your ability to enhance the application further.

Maybe it's time to think about a complete, ground-up rewrite which allows for all the new features you've added over the years as part of the 'baseline' design.

I know this is not a pleasant thought, but just like an automobile or a dishwasher or any other appliance, there comes a time when software's useful life is over.

[Tom Hanlin]

I'll put 'em on the wish list. I'm not sure they will be practical
to implement. Both limits are what they are for sound reasons.

Possibly, there are other ways to get there from here? I imagine
that there must be some large fixed-length strings or arrays within
the UDT(s) in question. It might be that these could be replaced
by pointers to data kept elsewhere. A pair of translation routines
could be used to handle any changes needed at "read from file" and
"write to file" time.

An excellent way to cut down on the number of parameters that need
to be passed is to pass them in UDTs. If need be, a fully generic
approach to this would be to pass a simple array, where each array
element is actually a pointer to a "parameter".

------------------
Tom Hanlin
PowerBASIC Staff

[Paul Squires]

Originally posted by Mike Luther:
Second request:

* Is there any way to expand the allowable number of call parameters
* from the current 16 to 64?

Maybe you can design a simple TYPE structure that emulates the
parameters you wish for the function, and then simply assign the
members of the Type and pass the Typeas a paramter of your function.
That way, you are only passing one variable. In your function you
can access the members of the Type variable as you desire.

If you are passing a lot of dynamic strings to the function then
maybe you could create a dynamic string array before calling the
function and then access those array indexes from within your
function. Upon returning from the function call you could then
assign the array values back to the original variables as
needed.

This may all be a little cumbersome, but it should allow passing
more values, with fewer parameters, and no globals.



------------------
Paul Squires
FireFly SDK Designer - "Visual Designer for PowerBASIC"
Cheetah Database System - "Nothing runs like a Cheetah"
JellyFish Pro Editor - "Custom code editor for PowerBASIC"
www.planetsquires.com
mailto:[email protected][email protected]</A>

[Mike Luther]

Two very specific changes in the current limits of PowerBasic 3.5
for DOS (And upward into LINUX when ..) would greatly help me.

First request:

* Is there any practical way to increase the maximum size of a
* TYPE structure from the current 16384 byte limit to 32768 bytes?

I badly need more struct room in my professional management case
template storage design for the data storage file. I use the TYPE
struct concept to orchestrate the record for the file. Right now
the only way I can see to handle the needed data storage space is
to make a side-saddle second file which uses the same record
pointer number as the primary file, then get the same record number
from the second TYPE structure from the side-saddle file. If the
above could be accomodated, the program suite update for the future
would only then likely be to simply merge the two files back into
what is now only one file. But I'd know where I was headed in the
future when the new product came available.


Second request:

* Is there any way to expand the allowable number of call parameters
* from the current 16 to 64?

Even that isn't quite large enough for my worst case SUBS that have
been very successfully used for years. But 64 would be a HUGE help.
I really don't want to use PUBLIC any more than some folks have for
so long advised one not to do. But without an expansion of a current
allowable maximum number of calling parameters to SUBS there is simply
no help in cleaning this up from code which has been working very
beautifully for many years with a carefully orchestrated PUBLIC venue
of variables.


Thank you very much for what could be done here. I believe that to
do both of the above would significantly improve the PB toolset for
use in very large facility wide program suites like my product.


------------------
Mike Luther
[email protected]