|
|
Post by mueh on Jun 6, 2024 7:23:52 GMT -5
Hi George !
Since 24069 lvl UNDO and REDO dont't display a msg . No Problem at 24026 lvl .
Maybe a side affect of Msg enhancement implemented in 24069 and similar to thread from 31/3/2024 in Problem and Bugs .
Thanks
Forget problem .
Sorry i had defined a (Home) key before the UNDO cmd in the key definition to keep the cursor where it is .
The undo is there twice because i think ( long time ago i made that change ) res creates an UNDO entry .
(SaveCursor)(Home)[res cmd](Enter)[UNDO](Enter)[UNDO](Enter)(RestoreCursor)
After diagnosing it more the problem occures when RestoreCursor is done which clears the msg .
|
|
|
|
Post by Robert on Jun 6, 2024 9:17:22 GMT -5
Perhaps the actual issue is the presence of commands that clear the msg. George, is there a way you can scan for the presence of 'clear message' actions in commands? Perhaps some don't need to be there.
Otherwise, maybe these commands normally really do need to clear the message, but there are cases where people still want to see it anyway? Would a kb primitive like (ShowLastMsg) be of some help?
R
|
|
|
|
Post by George on Jun 6, 2024 12:15:19 GMT -5
Commands themselves don't clear messages. When I made changes to the handling a while back, it was because a macro's Post_Do commands ended up clearing messages issued by the macro itself.
Basically messages are cleared by the first user interaction following a screen refresh. I corrected MUEH's latest problem by just adjusting where in the message processing path the clear happens. It really had nothing to do with (ResetCursor).
I'll post another Beta.
George
|
|
|
|
Post by mueh on Jun 6, 2024 14:08:10 GMT -5
Hi George !
Thanks for 24158 . It solved the clearing of Msg when (RestoreCursor) was there .
24158 now gets Invalid Command : BV
on cmd 'BV ?' . No Problem when BV without parameter is done .
Set contains ALIAS.BV=BACKVIEW
Did you make change in SET with 24158 ? (No problem with 24157)
|
|
|
|
Post by George on Jun 6, 2024 14:11:24 GMT -5
MUEH: Yes SET has altered. Let me check it out.
George
[UPDATE]
As the saying goes - Aaaargh! Very dumb coding when implementing Robert's ALIAS phrase suggestion.
I'll post a new Beta tomorrow.
[/UPDATE]
|
|
|
|
Post by mueh on Jun 8, 2024 13:09:26 GMT -5
Hi George!
Installed 24160 .
I have a modified BACKVIEW which excepts 'l' as a parameter . (list)
However 'bv l' results now in BACKVIEW L .
The parameter is now passed as Uperecase .
I think it should be passed as specified . ( to be compatible with before 24158 ) .
Thanks
|
|
|
|
Post by Robert on Jun 8, 2024 13:19:14 GMT -5
Mueh, SPFLite follows the IBM policy of treating all unquoted text as if upper case. And generally, user-written macros should be designed to do the same, so that you never have to be concerned about the caps lock key when you run a macro except for quoted strings.
But you're right, "treating" unquoted parameters as if upper case is NOT the same as forcibly changing them to upper case, which should not be done. If that's what's happening now, it may be a bug in the new parser code.
R
|
|
|
|
Post by George on Jun 8, 2024 15:03:40 GMT -5
MUEH: Robert:
Yes, the new code unnecessarily uppercased the words. I've removed that.
But still, the macro really should handle that.
New Beta tomorrow.
George
|
|
