This is rather elementary, but I am new to OI.

I wanted to set a default on a form control to the value of a synonym dictionary item, which does a lookup based upon the data in another field. However, I found that I can't just put the {DictItemName} in the default field, as I could in Rev G. I finally called, and was told I have to create a stored procedure, which I did, and it worked. In Rev G, I could put in a literal, a subroutine, or a {dictionaryItemNeme}, and I was done. Why can't I do that with OI?

Also, I found that in the stored procedure, I had to open the dict of the file to @DICT, which should have already been set from the form. It didn't have a problem with @RECORD already containing the record from the form, so why do I have to re-open for @DICT?

David Kralman

David,

I wanted to set a default on a form control to the value of a synonym dictionary item, which does a lookup based upon the data in another field. However, I found that I can't just put the {DictItemName} in the default field, as I could in Rev G. I finally called, and was told I have to create a stored procedure, which I did, and it worked. In Rev G, I could put in a literal, a subroutine, or a {dictionaryItemNeme}, and I was done. Why can't I do that with OI?

Using the {} syntax in a control's "Default" property has never been implemented. Actually AFAIK this is the first time anyone has asked for it, but I could be wrong there :)

Also, I found that in the stored procedure, I had to open the dict of the file to @DICT, which should have already been set from the form. It didn't have a problem with @RECORD already containing the record from the form, so why do I have to re-open for @DICT?

The problem with this approach is that OI is not a linear 'single process' application - Windows in Arev/RevG are opened and closed in a linear fashon one at a time - easy to track.

In OI (or Windows apps in general) it's possible to have many forms open at once, all of which could be bound to different data tables, and the value of @dict would have to change in a similar manner to @window as a user navigated through them and fired events (this is not impossible but would add in overhead which I'm not sure everyone would want).

However, the real problem here is that @dict is global and settable by any process in the system - I've seen idletime background processes hit items like @dict and @id and other user-defined stored procedures called from events may do the same unless they are well written to be aware of this and set the original values back after using them - Not something that can be guaranteed (We found this issue in the early days of SList development during yield cycles when displaying a report)

To be on the safe side it's always best to open the table and load @dict yourself - that way you know exactly what's in it.

The Sprezzatura Group

World leaders in all things RevSoft

RE: @RECORD, @DICT, @ID etc.

And the solution is for OI Forms to provide private data sessions ala Visual FoxPro:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_foxhelp/html/dgtskusingdatasessions.asp

Thanks for the explanation. that really helps. I'm so used to the DOS environment, I forget that Windows is different.

David

ZZ] Using the {} syntax in a control's "Default" property has never been implemented. Actually AFAIK this is the first time anyone has asked for it, but I could be wrong there :)

In AREV 1.1 at least you have (had) the option to select from the Default options popup:

" Duplicate data from previous record

{NAME} Symbolic

and last but not least:

@code command@

I have missed the reference to {PROMPT_DEFAULT} and already asked for it. Anybody else?

The " data duplication is also handy.

Walter, ELZET80

Walter ..

like so many things in Arev these would be nice add ons .. BUT since the originators of OI (lab geeks who didn't do applications :) knew no better and listened to the Dark Overlord .. well that is an old story.

I suggest that you put these in the 'enhancement' section of problem tracker ..

In the mean time .. some of these are easy to duplicate .. such as the 'dup' data. simply save off the record into a 'window' @var ..

Lots of work that it would be nice not to do though .. i hate work-arounds ..

dsig

View this thread on the Works forum...