|
Templates, Tools and Utilities
for Clarion Developers
|
 |
 |
|
Icetips Article
Back to article list
Search Articles
Add Comment
Printer friendly
Direct link
Par2: Dynamic Pool Limits
1997-10-08 -- Jim DeFabia
Dynamic Pool Limits - What They Are, How To Avoid Them.
The following was extracted from a CW-Talk IRC Chat Session. It covers
Dynamic Pool Limits, their causes, and how to avoid them. Thank Jim DeFabia
for this great information!
-
A "Pool" is an area reserved for your data and the data about the program
that he compiler uses. There are 4 pool limits in CW. 2 are very obscure (so
obscure I forgot what they are!) so let's discuss the common ones
1) TSCLAW.IDN
2) ISLPLIST
TSCLAW.IDN is the "name space" that the compiler reserves in advance and
uses during compilation. This name space pool holds all the labels in your
program data declarations, procedure labels, variables, etc, including
Keycodes.clw!!!
A label defines a specific location in a PROGRAM. Any code statement may be
identified and referenced by a label. For example:
fred EQUATE(1)
declares a Fred var which has a value of 1. Fred is its LABEL. If you hit
this limit, the solution is pretty simple. Shorten the names you have used
as labels (for example, change GlobalUserIDNumber to GLO:ID). If that is
not sufficient, make a copy of keycodes.clw and equates.clw and remove the
ones you do not need.
If your Clarion.Red (redirection) file has a . at the beginning of the .CLW
line, you can put the new edited keycodes.clw and equates.clw in the current
dir and that one is used instead of the default one in \libsrc. Keep in
mind that if at a later time you need a keycode that you have removed, you
will have to add it back. There are many keycodes which you may never use
(for example ctrl+alt+click with your nose). Don't forget that if at some
later date you want to use ctrl+alt+click with your nose, you will have to
add it back
IMPORTANT POINT:
Extra keycodes.clw add to dynamic pool. The more labels you use, the
closer you get.
2) ISLPLIST
To avoid this limit, move code to routines. This is a good idea anyway
because it makes it easier to maintain your code. Now, I know that much of
the code is created by the templates, and improved templates will help (IOW,
templates that put as much code into routines as possible).
In the accept loop we have CASE EVENT()s for each control so the most common
pool limit users find is a heavily populated form. This can be controlled
without modifying templates in a few differnet ways. The first is examine
your database design. If you need the mythical 1000 fields on a form, you
can still overcome the gen'd code. Copy the accept loop code to a routine
and use OMIT() to omit the entire gen'd code in accept loop, then call the
routine in the accept loop!
NOTE: There is a FREE Template available available at
www.pointofsale.com/developer called DPLHELP that does this for you. It
moves your entire procedure into a routine. This alone can help solve the
Dynamic Pool Limit error.
A final ( and more drastic) solution is to copy all the code and use a
SOURCE porcedure. This loses all the power of the form template, but if you
need to do it to ship, it can be useful.
Other Tips:
Turn off DEBUG in your Application Project.
Use one Module per Procedure.
Edited by: John Hickey
Today is April 24, 2024, 4:58 am
This article has been viewed 35108 times.
Back to article list
Search Articles
Add Comment
Printer friendly
|
|
|
