Announcement

Collapse

Maintenance

The forum could be offline for 30-60 minutes in the very near future for maintenance (said 3pm Pacific). I was behind on getting this notice. I do apologize.
See more
See less

Feature Request(s) for next DOS version.

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Feature Request(s) for next DOS version.

    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]
    Mike Luther
    [email protected]

  • #2
    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>
    Paul Squires
    FireFly Visual Designer (for PowerBASIC Windows 10+)
    Version 3 now available.
    http://www.planetsquires.com

    Comment


    • #3
      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

      Comment


      • #4
        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.

        Michael Mattias
        Tal Systems Inc. (retired)
        Racine WI USA
        [email protected]
        http://www.talsystems.com

        Comment

        Working...
        X