Can I handle Window Levels? (AREV Specific) [Revelation On-Line Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
[[https://www.revelation.com/|Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community]]


==== Can I handle Window Levels? (AREV Specific) ====
=== At 20 OCT 2006 12:17:18PM Michael Slack wrote: ===
 
{{tag>"AREV Specific"}}
 
<QUOTE>
We're running AREV 3.12.  We can reliably get the error message at debug of:

'RTP57' Line 1. B114 Maximum number of variables exceeded.

Line 1 'Catalyst' broke because a run time error was encountered.



How we can get this is by opening a window.  From the key prompt, hit the option (F2), which for us brings up our in-house built browse process that we've been using for years (and hasn't been modified in a few years).  A key is selected and it's sent back to the window as if the user typed it in.  The row is displayed on the window.  Without making any changes, the user hits F2 on the key prompt again and browses and selects another row.  Each time they do this the Window Level Number (lower right hand corner of the AREV screen) is incremented.



About Window Level Number 7 or 8, we break to the debugger with the message above.  In playing with this and checking WHO right before it breaks to the debugger, "available memory" is very low and the "descriptors used" number is well above 5000.



I've tried to introduce FLUSH and GARBAGECOLLECT into the process (between each browse/selecting of the keys) but it didn't have any effect.



Is there anyway to reduce the @WINDOW.LEVEL number and let go of some of the "variables" and free up some memory?  So that the user can keep browseing and selecting keys all day long without having to get out of the data window every few rows?



Thank you for your time.

Michael Slack
</QUOTE>
----

=== At 23 OCT 2006 09:00AM Dave Harmacek wrote:  ===

<QUOTE>Sounds like the process called from the F2 may be doing an EXECUTE and uses up memory.  Tell use how the F2 program is invoked (the Code Command in the Options section of the Key prompt).  Then, how the program finds and presents a list of keys.  Are there any Named Commons filled?  Do the Window Common Variables BROWSE_NEXT get filled? or how does the chose key get back to the prompt?



@WINDOW.LEVEL merely reports a fact, it is not causing your problem (IMHO).



Have you done a WHO to see if Expanded Memory is working?



Dave

</QUOTE>

----

=== At 23 OCT 2006 10:49AM Michael Slack wrote:  ===

<QUOTE>Yes, ultimately an EXECTUE is used.  Here is basically what happends.  From the window's key prompt the user hits the F2 for options.  This kicks off a Code and Command that calls the main program for the window.  The routine called, in turns calls a browse program that displays browse options the user can choose from (a simple popup).  This browse program may be called from other screens.  Once they choose something, that sets up some variables.  Then our BROWSE_INDEX program is called.  This handles all of our browses.  From getting the data, to displaying it on the screen to what to do once a value is selected.  In this case, once the user selects a row to display, the Execute executes the window and the key of the row selected by the user.  From your comments and questions, I take it that this is where the window level gets incremented and more variables and memory is used.



As for Expanded Memory, I do remember noticing that it was active when I was looking into this problem.



Among the three programs, there is some common variable used.



Is there any hope?  The BROWSE_INDEX program is a mess.  I try not to touch it if at all possible.  It may be something we'll just have to live with.



Thanks,

Michael Slack

</QUOTE>

----

=== At 23 OCT 2006 11:22AM Victor Engel wrote:  ===

<QUOTE>EXECUTE initiates a whole new environment, preserving the one from which it was called. The environment is cleaned up when you return from it, but from your description, you're not returning from it. Even if you have infinite amounts of expanded memory, you will still run into the problem you're facing, because Arev uses only a finite number of descriptors.



If you're going to use EXECUTE, then you need to return from that execution level at some point.

</QUOTE>

----

=== At 23 OCT 2006 02:37PM Ralph Johler wrote:  ===

<QUOTE>We recently had a similar problem which ended being caused by symbolics.



The user would look up a customer in one window, from that window using a softkey, lookup an order, from that order window...blah blah we had up about 5 to 7 tcl levels when it all blew up.



Sometimes it would work.  Sometimes not.   We had made a small change to one of the windows and it put us over the program stack limit.  It was that each window used symbolics, and the total sum of all those symbolics used up the program stack on us.



Try PSP from the debugger.  It will display everything that is running and you're probably over or very very close.  As I recall I had to manually invoking the debugger and the using PSP until I got close to problem step.



We had to change a few things to reduce the symbolics used.

</QUOTE>

----

=== At 24 OCT 2006 10:09AM Michael Slack wrote:  ===

<QUOTE>Thank you all for your help.  At least now I have an idea what and where my problem is and now I can see what I can do about correcting it.



Thanks,

Michael Slack

</QUOTE>

----

=== At 25 OCT 2006 09:56AM Dave Harmacek wrote:  ===

<QUOTE>The Arev Window Common variables can be used at the key prompt or from a Softkey:



Place the keys of interest, even one, @vm-delimited into WC_BROWSE_NEXT%



WC_NEW_BROWSE%=1

WC_NEW_ID%=0

WC_RESET%=RESET.RECORD$



where RESET.RECORD$=5



Yes, I think your EXECUTE is the problem.  You can use @USER variables to traverse to return results.



Dave

</QUOTE>


[[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=NONWORKS_READ&SUMMARY=1&KEY=CB6164B9F8ABDE8C8525720D005979B6|View this thread on the  forum...]]