Ah! So you saing I am fool that that can be tricked! How right you are -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of J. Stephen Wills Sent: den 22 november 2002 22:01 To: [EMAIL PROTECTED] Subject: Re: BASE 6.5++ Patch-3 and 7.0 (was RE: Labels)
Gunnar, I suspect that it's not always Razzak, but rather a functional test of the AI features of RBv8 that is actually issuing some of the responses ... ;-) Later, Steve in Memphis ----- Original Message ----- From: "Gunnar Ekblad" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, November 22, 2002 2:20 PM Subject: RE: BASE 6.5++ Patch-3 and 7.0 (was RE: Labels) > Razzak > I know we are on different time zones. Can I ask do you sleep? No mater > what time-zone you give some answer. > Anyway I can wait but, not much longer for 7.0 > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > On Behalf Of A. Razzak Memon > Sent: den 22 november 2002 20:44 > To: [EMAIL PROTECTED] > Subject: R:BASE 6.5++ Patch-3 and 7.0 (was RE: Labels) > > > At 09:19 AM 11/22/2002 -0600, Dennis McGrath wrote: > > >Wouldn't it be wonderful if we could also define variable definitions > that > >would be stored in the database? That way they become an integral part > of > >the database and we could never forget to define these required > variables. > >Unloads would never trip over missing global variables. > > > >The variable(s) would be created, when necessary, every time the > database > >was opened. > >The default value would only be supplied upon creation. > >Those defined to be NOT NULL would never be allowed to be set to NULL. > >CLEAR VAR or CLEAR ALL VAR would not destroy it. > >We could LIST STATICVAR to see what static variables are defined. > >DROP STATICVAR varname would remove the definition. > > > >We could say, for example: > > > >CREATE STATICVAR vStartDate DATE = (.#DATE) NOT NULL > >vStartDate is always present, defaults to today, and cannot be set to > null. > > > >CREATE STATICVAR vTemp TEXT > >vTemp is always present, but does not have any default value and can be > >NULL. > > > >I think this would be an incredible enhancement. Could I hope for it > in > >6.5? 7.0? > > > At 11:07 AM 11/22/2002 -0500, Larry Lustig wrote: > > >I would make two (mutually exclusive) suggestions: > > > >1. Your idea of static variables be maintained in a SYS_VARIABLES table > so > >that they could be queried and manipulated with SQL. > > > >2. That a bunch of additional trigger opportunities be added: > > > >ON_CONNECT > >ON_DISCONNECT > >ON_MODIFY_FORM > >ON_SAVE_FORM > >ON_MODIFY_REPORT > >ON_SAVE_REPORT > > > >This would let you add some code to ensure that, whenever you change a > form > >or report you create the necessary variables when bringing up the > designer. > > > Dennis McGrath and Larry Lustig: > > Crikey! (means WOW in Australian) > > Thanks for the GREAT ideas! > > As of today, the In-Line Patch-3 (Build:1.860xRT03) includes 32 > Enhancements > and 46 Bug-Fixes, since the release of Patch-2 (Build:1.851xRT03). > > Thanks to all beta testers for their sincere efforts to help us bring > the > best of > R:BASE 6.5++. The best and the longest beta version is finally going to > release > and there is absolutely no chance to add your valuable enhancement > requests > in 6.5++ at this point. However, these are definitely enhancements that > we'll > try to add in 7.0. > > Our goal has been to make the 6.5++ rock solid with a few added > enhancements > to provide the BEST version to our LOYAL and CURRENT R:BASE Users and > then continue to use our resources and talents towards the Next > Generation, > R:BASE 7.0 for Windows. At this time 6.5++ development is over and we > are > simply tying to resolve any minor outstanding before it is released. > > So, sit back, relax and enjoy the hard work of the Dream Team who have > worked > very hard to provide you all with the 6.5++ In-Line Patch-3 and we'll > now > dedicate > their efforts solely towards the development of R:BASE 7.0. > > The BEST is yet to come! > > Very Best Regards, > > Razzak. > > > ================================================ > 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/ > > ================================================ > 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/ ================================================ 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/ ================================================ 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/
