Repost Asterisks in record ID's -- RTI folks? (OpenInsight Specific)
At 27 MAY 1998 12:16:07PM Alex Eloquent wrote:
I'm going to need to make a decision on this pretty soon, so I'd appreciate it if someone would have a look at my previous post and let me know if there's *any* way to accomplish this (asterisks in the key field which do not cause OI to deal with multi-part keys) without completely replacing the system READ and WRITE events.
TIA,
acruise@istar.ca
At 27 MAY 1998 01:55PM DSig (SigSolutions) wrote:
Alex,
I *believe* the form logic automatically parses the "*" and there is no way to override the default behavior unless you override the event stream ..
dsig
David Tod Sigafoos ~ SigSOlutions
dsig@teleport.com cis:70302,77 voice:503-639-8080
At 28 MAY 1998 05:45PM Cameron Revelation wrote:
Alex,
I'm going to need to make a decision on this pretty soon, so I'd appreciate it if someone would have a look at my previous post and let me know if there's *any* way to accomplish this (asterisks in the key field which do not cause OI to deal with multi-part keys) without completely replacing the system READ and WRITE events.
It appears to be a limitation of MergeRows(). I've looked at it some and may be able to give you a work-around or ….
Cameron Purdy
info@revelation.com
At 29 MAY 1998 10:12AM Cameron Revelation wrote:
Alex,
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.
That is the first issue you have to deal with. Place the following in your CREATE event:
<code> $insert OIWin_Equates WinID=@window $insert OIWin_Comm_Init Pos=KeyMap@ if Pos ] 0 then ControlSemantics@=0 end i=1 loop Pos=RowMaps@ if Pos=0 then RowMaps@=0 end while Pos i += 1 repeat return 1</code>
Here is the hex dump for MergeRows() … you will have to replace SYSOBJ/$MERGEROWS with the following:
000E000500DF00C8010000C4C5C4C5ED E807EEECC00242640207EF644063EFEE 644CDB00F0ECEF63631E07F06465631E 489500F06468631E487E00F1E9F06465 631E63631E07F2F06468631E07F3F1C0 0342640207F36454486D00EB6454486D 006480D780E0410280AE29B8EDA7F064 67631EEB63F1F26E1B404A9200EDA7F0 6467631EEB63E9F06465631E63631E1B 404AD700F4F06466631E07F448AB00F5 EA80DEF4641F074AAE00F5EA07F06468 631E48CB00EDA7F06467631EEB63F5F0 6468631E6E1B404AD700EDA7F0646763 1EEB63F51B40644A1F00ED29B8740657 494E444F5708434845434B424F580843 4F4D424F424F5808454449544C494E45 09454449544649454C44074C49535442 4F580A50555348425554544F4E0B5241 44494F425554544F4E0A524144494F47 524F55500449434F4E044D454E550642 49544D41500745444954424F58084752 4F5550424F58095343524F4C4C424152 09454449545441424C4508524144494F 424D5008434845434B424D5007505553 48424D5006525446424F5800094E4F54 4553464F524D094E4F54455356494557 0B4E4F544553464F4C44455207444154 4153455406524550333130012A0A5345 545F5354415455530205010101020101 010000180053595350524F47FE313131 30372E34313834303237373738250072 6573756C74526F77FD70617274526F77 FD6B6579FD737562526F77FD6D657267 654D6170Cameron Purdy
info@revelation.com
At 01 JUN 1998 12:37PM Alex Eloquent wrote:
Wow! That's more than I ever expected. Thanks, Cameron!
I already had the modifications to KeyMap@, ControlSemantics@ and RowMaps@… But obviously it wasn't working. :)
I suppose I'll need to de-hexify that before I write it to SYSOBJ, eh?
And… Will that change be overwritten when I upgrade to 3.6 or future releases?
Thanks again,
acruise@istar.ca
At 01 JUN 1998 02:15PM Cameron Revelation wrote:
Alex,
Will that change be overwritten when I upgrade to 3.6 or future releases?
Assuming you find no side-effects, I will put it into the next release.
Cameron Purdy
info@revelation.com
At 01 JUN 1998 04:48PM Alex Eloquent wrote:
Well, with the new $MERGEROWS, everything looks great! I'll keep you posted if I find any problems. :)
Thanks!