Will somebody please test the following line of code and tell me what you get:
call msg(@window, "My email is [email protected]")
I believe there is unique bug in Msg. The "@PARAM" in the above email address is getting substituted like a replaceable parameter.
Don,
Neat.
For variations try [email protected] and [email protected].
Note that with [email protected] the o that follows @param gets eaten. I think @paramo (and possibly any @param) gets interpreted as @param0. @param is buggy too but not so interesting. @param1 crashes the engine. To avoid fatal problems with your app I recommend you buy all possible domain names containing @param1 immediately.
- Oystein -
To avoid fatal problems with your app I recommend you buy all possible domain names containing @param1 immediately.
Agent C
Sorry, Don. I didn't mean to poke fun at you. I just didn't know if I should laugh or cry. I chose to laugh.
- Oystein -
C,
Really? Have I soon deserved the right to sign with Polly Puffin?
- Oystein -
Oystein,
No worries, I laughed (at least on the inside). My issue at that moment was meeting a deadline for deployment yesterday. FWIW, I was able to duplicate the problem for any window using a CreateParam parameter. This meant that I could not create a workaround to MSG since MSG itself is not the problem.
My only solution (unless someone has a better idea) was to check to see if "@param" appears in the message text. If so, I insert a space before and after the @ symbol so it looks like this: dbakke @ paramount.com.
Oh well…
'Nother Don ..
FWIW, there are other gotcha's when using any word prefixed with an @-sign. The compiler will certainly cough on it; in windows it is treated as a user-defined global @MYSTUFF which I use to save the create-parm; R/LIST can get lost and hang up. It's like an * in a key when there ain't no 2-part keys defined. Just try to get that back!
UUUUUUUUUUgly in the extreme.
Don Miller
C3 Inc.
Don M,
It wasn't difficult to repeat Don B's experiment, but what's all the other @ stuff you're talking about?
- @ystein -
Don,
I tried this and didn't get the problems you seem to be experiencing, although it wasn't working as I expected.
I did find more success using Msg2 however (Msg2 is the previous version of Msg that RTI saved within the system).
Might be worth trying that
Simon
Rebus Software (UK) Ltd
Oystein ..
For a long time Rev has used the Pick convention of treating system variables as having an @-sign prefixing reserved-word variables. Some examples are @RECORD, @ID, @DICT, @USER, @RECUR, @RECCOUNT, @ANS, @FILTER,@LIST.ACTIVE, @SAVE.SELECT, @LOWER.CASE, @UPPER.CASE, @FILES, @VOLUMES, @USERNAME, @LPTRHIGH, @LPTRWIDE and who knows what else are system variables. If they were treated as regular variables, things could get messed up in a hurry. My suspicion is that some of the OI code treats anything prefixed with an @-sign as being a "reserved" word. Ditto with the windows convention of the &-sign. Our scheduling product Schedule People & Time or SP&T, fondly known as SPIT, give us fits when coding messages, etc. for display. Hot keys, etc.
Don Miller
C3 Inc.
Don,
Can you use the Message_Box function instead? (Or the Windows MessageBox function.) It seems to display [email protected] ok.
- Oystein -
Don,
Didn't know about the problem with & in Msg. But try && - e.g SP&&T.
- Oystein -
Don,
My suspicion is that some of the OI code treats anything prefixed with an @-sign as being a "reserved" word.
At least with Msg it's not "anything". It's just the various @-stuff you can use in quickevents - @Window, @Self, and @Param0 through @Param9. (Or to be more precise about the @Param ones: OI seems to check for just @Param and treat the next character as 0 if it's not a digit.)
But I'd be grateful if you can give me a couple of specific examples of the other problems you're talking about. (I assume you read my response about & in Msg, but you seem to have others up your sleeve.) Sorry if I seem slow.
- Oystein -
Oystein ..
See what happens if you accidentally put @DICT into MSG. You'll love it after you reboot your machine! Since you are probably better qualified about MSG in OI, I may have mis-spoken about all the @-variables. Given what I know about RTI, though, it would not have surprised me in the slightest if the MSG call (vs. MSG2 by the way) might misinterpret @-variables. I did note the @PARM ignoring 1-9 and assuming 0 .. what a wonderful assumption .. I'm much more used to the AREV @-vars, though. BTW, I know about SP&&T. When I'm in a hurry, I tend to forget.
Cheers..
Don Miller
C3 Inc.
Don,
See what happens if you accidentally put @DICT into MSG
All right - since I'm closing down now anyway. It's getting late around here.
![]()
- Oystein -