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

At 15 MAY 1998 05:45:32PM Alex Eloquent wrote:

As few of you may know, we use a peculiar format for record keys in our application, which we call "NumCrunch".

In essence, keys are stored as a string of ASCII characters from #0 to #246. In AREV, we ran into a problem when the internal representation for a key started with a backslash or forward slash. We got around it by using Replace Scribe and Post processes on the key prompt.

Slashes seem no longer to be a problem in OI, but it turns out asterisks are! So, my question is this: When a key includes an asterisk internally, how can I trick OI into reading the records properly anyway? Right now, it interprets a key that looks like "a*b" as just "a". This is only a problem for approximately 1-in-246 records, but it's a problem.

Any clues? We can't really just block out certain numeric ranges of keys, because people have alot of old records entered in the AREV version of our app.

TIA,

Alex

[email protected]


At 16 MAY 1998 04:05PM Dave Pociu wrote:

Alex,

Choice 1:

You could include a hidden second edit line control that looks at 0*2. You can the save your key in an @property of the window on LOSTFOCUS of the MAIN key control (the one the users see). Then on the READ event, look at the saved key. If it has asterisks, then programatically fill in the hidden edit line control and let the app do the read. (you might also have to re-fill the key control that users see after the READ with the full key - so that it look the same to the users).

On write, same thing: if there is no asterisk in the @property, do a straight save, otherwise fill in each field accordingly and then let WRITE continue.

Choice 2:

I usually do something very similar to what you are describing by using these GATHER/SHOW utilities that I wrote. What they do is they allow me to gather the data from selected controls on the screen into a variable and conversely distribute data from a variable to multiple screen controls automatically.

With these utilities, I wouldn't need a second control. I would do the following.

1. get the key (asterisk and all) and store in an @property

2. use READ @record from table,key

3. use the SHOW( @window, @record, key) to display the data from @record to the screen

4. At write time: use GATHER( @window, @record , key) to gather my screen data back into @record

5. write @record on table, key

So pretty much, for "special" data, I can avoid the automatic READ/WRITE because of being able to create the @record variable from screen controls easily on the fly. However, for all "normal" records I let the automatic READ/WRITE do its job

Hope this helped.

Dave

[email protected]


At 26 MAY 1998 11:40AM Alex Eloquent wrote:

Thanks for your tips, Dave…

I've given the first option (the one that requires less work :) a cursory try, but haven't managed to get it to work. My little test window has two key fields… One of them is 0*0, the other is 0*2. Here's what I'm doing:

- Into the 0*0 field, type a key whose internal representation does *not* contain any asterisks

- On the LOSTFOCUS event of the 0*0 field, store that key in an @property

- In the READ event, retrieve said @property and store the complete (non-asterisk) key in the 0*0 field, and "" (null) in the 0*2 field.

- Forward_Event().

- After the Forward_Event(), @ID still shows as *. The presence of the 0*2 control is causing OI to add an asterisk and an empty part 2.

I tried this with the 'main' key field being 0*1 as well, but it had the same effect.

Although I have the two key fields pointing to 0*0 and 0*2, oddly enough, they show up as 0*1 and 0*2 in OIWIN_COMM_EQUATES' RMap@ variable.

Curiouser and curiouser,

[email protected]

[url=http://www.eloquent-systems.com/]Eloquent Systems Inc.

View this thread on the forum...

  • third_party_content/community/commentary/forums_nonworks/7dbf7aa242943dd985256605007786b3.txt
  • Last modified: 2023/12/28 07:40
  • by 127.0.0.1