Lee,

I was not aware you were doing windows WITH a full screen console
minimized and pressing ALT key in combination with TAB now too...

I mentioned in my initial post that I "switched from full-screen console to
the GUI" I'm not aware of another method of doing that than by using a
keyboard-shortcut, so I didn't spell the ALT-TAB method out. But maybe I
should have, just to be on the safe side.

How can I know now what they did, how they did it so many years
ago? Perhaps the ALT key is being stored after you press TAB and I
can't know this either.

I do not know either, and was not out to getting an explanation for it
either (though I have absolute zero problems with getting to know why it
happens mind you. :-) ), I just tried to minimize the problem itself -- by
limiting how many items a double-click affects.

The issue appears to be two fold at the very least. You want ALTless
function in windows with

Nope, not at all. I'm not out for a "than just don't do that" solution.
Also, clicking the console windows button on the taskbar will also bring it
up in its previous, in my case, full-screen state.

AND without the full screen console minimized.

As I mentioned in the above, how else do you leave a full-screen console
window (and no, ALT-ENTER (to window the console) and than mousing to the
desired dialog does not count. :-) )

But you're focussing on something I did not ask for.

What I *really* want to know (at least as a first thing) is if there is a
setting/method to limit the reach of a double-click. If that is available I
could not care less about the ALT (or any other) key appearing to be sticky.

Yes, a sticky ALT or CTRL key (c|w)ould than still bring up dialogs, but
none as potentionally dangerous as starting a slew of programs, scripts and
batch files I have in a particular folder.

Regards,
Rudy Wieser


-- Origional message:
Lee schreef in berichtnieuws
...
Sorry, got busy.

On Saturday, April 1, 2017 at 2:22:50 AM UTC-6, R.Wieser wrote:
I seldom use ALT-ENTER. I however do use ALT-TAB to
switch between the (full-screen) DOS prompt and the GUI ...

This reveal blows apart some prior advice. I was not aware you were doing
windows WITH a full screen console minimized and pressing ALT key in
combination with TAB now too...

Keyboard buffers exist on many platforms, you perhaps didn't spend any time
on an Atari 8 bit or others of that ilk where each system's keyboard had the
buffer set up and used in a vast array of foibles. Often when the OS has
been loaded with custom software that uses a different technique than the
maker to capture key presses, the keyboard buffer can be filled with presses
not intended to be sent when the software has finished and run it's course.
And at that point here come the last 5 keys or none of them or just one
depending on make and model. Windows OS uses a keyboard buffer too,
different from DOS most likely and to get into full screen mode with the
'set for it' full screen setting it is pressing it's own ALT-ENTER combo for
you. Windows remembers this key press because it's in the buffer. Perhaps,
perhaps not if they foresaw this issue and piddled with the buffer such that
it doesn't show there at all. How can I know now what they did, how they did
it so many years ago? Perhaps the ALT key is being stored after you press
TAB and I can't know this either.

Upon exit then, DOS mode should clear that keypress for you, but only that
one and most likely only if it's really there and again only if it's stacked
correctly and not out of phase with any other buffered key press. Your trips
into the GUI via ALT-TAB are blowing the order of the buffer stack such that
it can't possibly wind up right. We can't even be sure of which one is
blown.

You don't need to preload the windows keyboard buffer with this
ALT button press which may be the root cause of the issue.

I'm not sure what you mean here ... Preloading ? How ? I'm not aware
of
that (and than, what about the TAB key I also need to press ?).


Excellent example of phase issues, I'm talking about one method and you are
talking about a different method only revealed to me after my 2nd round of
suggestions has confused you because you didn't let me know your methods in
detail. So my advice can't possibly be correct and in order to follow, you
have to go back and see where I'm speaking to an issue that isn't yours. Do
that to the windows keyboard buffer and you have your problem complete with
intermittent aspect too.

I suffer issues with windows only use of ALT-TAB as is, it's kind of a crap
shoot and I only win sometimes. Combine that with firefox's inane approach
to 'TAB winders is way more better than a new winder' where they confuse the
order of open windows purposely to 'encourage' the use of their built in
TABs insanity and I want to shoot somebody sometimes.

Earlier you asked for where are the settings if there are any?

I was aiming for GUI settings (as there the problem is most pronounced),
but
I'm open to any help I can get. :-)


The issue appears to be two fold at the very least. You want ALTless
function in windows with AND without the full screen console minimized. I
suspect one simple solution doesn't exist for both uses. I was suggesting a
one shot only method and just like fighting indians you can't use your last
bullet on anybody else except yourself. That idea then can't possibly work
out well.


I'm not sure I'm really a power-user. Its just that some stuff just seems
to work easier in a CLI than in a GUI. *Especially* when you have some
"dump output" you want to view/capture into a file.


In my vernacular you are, it doesn't mean a buddha like knowledge of all
things comparable to and 2nd only to God himself, it just means you do that
often. End of definition.


If I'm not mistaken NONE of the BIOS calls can be ignored in that manner

I'm afraid you're mistaken. You just have to make sure that you do not
have both active at the same time, as that most likely will cause clashes.
:-)

Sorry, then by definition it's not a legal BIOS call and no software you are
likely to be using does illegal direct access as examples given. You can't
sell hacks commercially, virus software is looking for these hacks. And
principally to the point -- HACKS don't count by definition. DOS is using
only proper and legal BIOS calls, until you load DeBug and use it to hack
your way around for example. Windows also follows the rules. And those are
the rules.

The BIOS is not capable of multitasking anything.


pretty sure now it's just the settings/method you are using

I'm all ears ! ... but are you sure about that ? A sometimes(!)-sticky
key being caused by a setting ?


Do you ever recall such a sticky key checkbox? I don't.


Now I only need to come up with a method to, in a DOS environment, check
the
keys current status ...


Good luck finding both DOS keyboard buffer and windows buffer, really seems
to be the only way that could work is to clear pending and present key
presses on both. DOS for sure had it's keyboard buffer far in advance of
the existence of windows and the 32 bit protected mode crowd when they
showed up to play would insist on their own keyboard buffer, thus my belief
that there will be two buffers to deal with.


Thanks for the suggestions.

Regards,
Rudy Wieser

Certainly. If you find a solution please get back with it as it's going to
be more than I know about now. Last thought is perhaps an ALT press monitor?
Something that would alter it's icon color to indicate ALT has been pressed
and/or is a pending key press? Vb script can be running in the background
doing this one and only job - perhaps, I'm not entirely fluent in that to
say for sure. ALT-TAB would be different than just ALT as a reminder. And
this is a rather poor workaround as it still leaves you pressing ALT anyway
which was the workaround you don't want.

Of course I can't find my own send_keys examples as they are on another
computer not accessible at the moment. Main help came from the help file
from vbs 5.6 itself.
Not a whole lot out there still intact, but I did find these two still
working.
http://www.billsway.com/vbspage/
http://computerperformance.co.uk/