TOO MANYs READ IN EFFECT 1

[Guest_imported]

Hi !

I did screens as menu (sub menu is a new screen) but when I'm deeper than five menus I get the error "TOO MANYs READ IN EFFECT" or something like that.. I tried "clear read all" to erase reads in effect but same result.. I really need up to five sub menu so I have to find a solution!

If someone has an idea about this problem...

Thank you!

 

[infinitelo]

are you calling procedures with your menu? if im not mistaken if you call a procedure you can use five more reads.

 

[Scott24x7]

Eric,
In FoxPro 2.x you only have 5 reads available. If you are using Screens as Menus, and you call each one as an independant Screen Set, each is getting it's own "READ" associated with it. This is occurs automatically when you compile (GENSCREEN) will generate code for each screen with it's own read. One solution, however, is to associate all of the screens with a single read. To do this, (Assuming you are using the Project Manager), double click on your first menu level. This will bring up a box Titled 'EDIT SCREEN SETS'. Click the ADD button, then add the name of each of the SCREEN SETS that you have as your additional MENUS to the list.
Now, that's the easy part. This is where it gets tricky. There are a couple of key things you must do here. First, the file name of your screen (like MENU2.SPR) must not match the acutal name of the screen (which is set in the NAME field in SCREEN LAYOUT). If they do, when you BUILD your project, it will give you an error that states something along the line of "SCREEN ALREADY DEFINED..." that is not the exact error, but it will not complete the build, so watch out for that.
What will happen ultimatly is your MENU will generate a single LARGE.SPR. You won't call the other MENUS as .SPR's, because they will be compiled as functions into your single MENU.SPR. You will need to reference them by their function names. You will also need to do things like HIDE WINDOW <WINDOWNAME> to &quot;HIDE&quot; them, since they will really be ever present. You will bring them forward with &quot;ACTIVATE WINDOW <WINDOWNAME>&quot;. You may need to compile once, and then look at the .SPR code for the primary MENU to see how it references the SCREEN SETS by name. (If memory serves correctly, it doesn't genereate unique names, since that would cause HUGE problems, I just don't rembmer off the top of my head how they get referenced.) I personally don't normally use this approach, because if makes for some very complicated screen handeling logic, and instead, I opt to use standard MENU functions with Drop Downs, and a foundation READ for handeling MENUS. It is a much simpler code endevor, and 5 reads is usually enough to deal with all my other issues. However, if you have a need to go this route, it can be done!
Cheers,
-Scott