I think a new thread is in order here. My suggestion for an enhancement for STATICVAR comes from 17 years of use of RBase, as well as recent forays into VB and object oriented programming.
I suddenly realized that so much of what I did for years to make my apps easy to maintain was, in effect, an attempt to make all parts of the app/database self sufficient. That is the key idea in object oriented thinking. You create objects that when called upon, have everything they need to correctly instantiate (a fancy word for create) built in. Once you have the object created, you can alter properties to make them give you results based on those adjustable properties. My recent post describing how I put variable definitions in my forms that referred to themselves was a way (although an awful kludge) to make my forms maintainable without having to remember to define certain variables beforehand. This has at least two advantages: 1. I can maintain the form without predefining anything. 2. There is a greatly reduced probability that I (or my clients!) will save the form in an unusable state. This has at least two disadvantages: 1. It uses up a valuable resource: variable definitions in a form. 2. The definition is a mystery to anyone who does not realize what it is there for. In RBDOS, anything over 100 variable definitions is asking for trouble. In RBWIN I have not yet run into the variable definition limit, but suspect it is lucking there. To sum up, Forms created in this way are friendly to me, the developer. They save me tons of time because I don't have to remember anything. I also don't get error messages when I try to maintain forms. But, there is one problem which keeps coming up. Forms created on views with embedded variables are not so friendly. They complain about missing variables, and they complain about illegal comparisons like null dates. The problem is that views with variables are not self contained objects like normal views. They rely on certain variables to exist and, in some cases, that they contain valid data. One could wish that the forms could process their variables before trying to check the underlying table, but that does not solve the limited variable resource issue, and it is not really the correct solution. One could wish that the views themselves could maintain these variables, but I suspect that would be an unnecessary complication. And it would not solve the need for other predefined variables that the forms or reports might need. The only really satisfying solution to this problem is if the database itself maintains the desired variables. After all, views and forms are objects contained in the database. So, if the database has the ability to enforce properly defined required variables (STATICVARs), all these problems go away. This is because the container object (the database) assures that all contained objects are always happy. The upshot of this is that I can be a responsible developer just once for each view, form, etc. I create. No code needs to be run once the database is opened. This makes me look good. This makes RBase look good. This makes the client happy (lower maintenance cost). These are all appropriate and valuable goals. --Dennis McGrath ================================================ TO SEE MESSAGE POSTING GUIDELINES: Send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: INTRO rbase-l ================================================ TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: UNSUBSCRIBE rbase-l ================================================ TO SEARCH ARCHIVES: http://www.mail-archive.com/rbase-l%40sonetmail.com/
