| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| subject: | Msged suggestion |
BG> There is one more thing I'd really like to see added to Msged,
BG> and that's the ability to perform an external operation without
BG> having to manually enter the command in a Msged prompt window
BG> (OLX uses token keywords for this).
What the fuck do you want to use externals for anyway ?
You should be using another multitasker window for that stuff.
BG> For example, if I want to run LIST or something like that,
BG> I currently have to do either of the following (this is in
BG> edit mode, but although the read mode keystrokes are slightly
BG> different, the principle is the same)...
You should just have List already open in another multitasker window,
and have some decent window switch mech in the multitasker itself,
like the Desqview Alt-n approach, even with something like OS2.
BG> 1. Press Alt-1, then enter the command name in the prompt
BG> window. When the external command or program has exited,
BG> I then have to press to clear the "DOS command
info" window.
BG> or
BG> 2. Press Alt-O, which shells to a system prompt, run the command,
BG> then type EXIT to return to Msged.
And there is none of that farting around with another multitasker
window, just use the same ALT-n approach go get back to the OLR
window when you want to. With the n permanently assigned by your auto
desktop restart or even more radical not turning the machine off ever.
Anything else is dinosaur technology.
BG> Neither are particularly elegant, and it would be much better to
BG> assign a keyword to a function key in msged.cfg. For example, have
BG> keywords such as {at}SHELL with replaceable parameters so that a commonly
BG> run apps like LIST or QEDIT2 can be invoked with a single Fn-key
BG> keystroke, then back to Msged as soon as that app closes, such as this...
BG> function 5 {at}SHELL list.exe
BG> function 6 {at}SHELL q.exe
BG> ...and so on (get my drift?).
Well, its clearly better than what you have now, but you
still have the farting around as the OS does that work,
loading that task and closing it again. Dinosaur stuff.
BG> I've tried doing this with macros, but as both the DOSCMD
BG> and DOS keywords require user input, it can't be done.
Urgh. Thats always been another area where DV pisses on OS2 too,
you can much more easily overlay key definitions on a particular
tasks window than you can with OS2. Its more than a tad non orthogonal
tho in that situation where you have both key definitions in the
app and the OS task config. Its doable in OS2, just not so elegantly.
BG> The other alternative would be to allow user-input parameters to be
BG> accepted from function key macros by enclosing them in quotes, like so...
BG> function 1 \0x78,"list.exe",\0x000d
Thats more than a tad too cryptic for the average user tho.
BG> ...where the first parameter invokes Msged's "DOS command window",
BG> the second (in quotes) runs the app or ute and the third clears the
BG> "command info" window and returns you to exactly where you were in
BG> Msged. The example keycodes are wrong, but would be calling DOSCMD,
BG> LIST, and respectively.
BG> So waddya reckon?
Dinosaur stuff.
--- PQWK202
* Origin: afswlw rjfilepwq (3:711/934.2)SEEN-BY: 690/718 711/809 934 @PATH: 711/934 |
|
| SOURCE: echomail via fidonet.ozzmosis.com | |
Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.