Euphoria Ticket #614: maybe_any_key

Maybe_any_key doesn't pause when a program with an extension .ex is run from Windows explorer.

Create a program: test.ex

include std/console.e 
maybe_any_key() 


On the command line test.ex just returns when run with eui -- good. On the command line when run with euiw, a Window opens ups and waits for a key -- good. If you double click on the program in explorer however a Window briefly appears and it just disappears without waiting -- bad.

Details

Type: Bug Report Severity: Normal Category: Interpreter
Assigned To: unknown Status: Fixed Reported Release:
Fixed in SVN #: View VCS: none Milestone: 4.0.1

1. Comment by jimcbrown Feb 10, 2011

I am not sure that I agree with the fix for this. If I understand correctly, then the behavior of has_console() has now been changed, and it's possible that programs which used to get rid of their console window will now have a blank console window lying around that won't go away.

A new function is fine, but changing the behavior of an existing function needs a lot more discussion.

2. Comment by ArthurCrump Feb 10, 2011

If you want it to run with euiw from explorer, try changing the name to test.exw

3. Comment by jimcbrown Feb 11, 2011

Am I the only one opposed? If so, I'll go along with the group decision.

4. Comment by mattlewis Feb 11, 2011

Jim,

I don't understand your objection. What's "the fix"? What Shawn brought up seems like a genuine bug in the way that maybe_any_key() is supposed to work.

Has some code been committed? How does it change the behavior? In the use case provided, there was no original console, so it seems appropriate that maybe_any_key() should ask for the prompt. I don't understand what the problem is.

5. Comment by jimcbrown Feb 11, 2011

A fix was committed as hg:euphoria/a8404dcdbac5 or see http://scm.openeuphoria.org/hg/euphoria/rev/a8403dcdbac5

My concern is the change here, in the docs, from:

-- Returns: 
--   1 if a console exists, 0 if a console does not exist. 

to

-- Returns: 
--   1 if there is more than one process attached to the current console, 
--   0 if a console does not exist or only one process (EUPHORIA) is attached to 
--     the current console. 

Process has a console, but we still return 0, so free_console() is never called and we're stuck with a silly window that's not used but never goes away. (This is the opposite problem from the one that the ticket is trying to fix.)

6. Comment by jimcbrown Feb 11, 2011

I mean, the fix does fix the original bug, but it (seems to me at least) risks introducing this new bug, which is the exact opposite of the original bug ... if that makes sense.

7. Comment by mattlewis Feb 11, 2011

Hmm....maybe not. If you were running a command shell, wouldn't you also have cmd.exe attached to the console? However, if euphoria opened the console itself, then I'd expect just euphoria to be attached. And this is the case where the console would disappear when euphoria exited. So I think that in fact Shawn found the condition to check that we really want.

Though we should probably document it better to explain why we're doing that.

Also, why wasn't the ticket updated to indicate that work had been done? It's still showing "New".

8. Comment by jimcbrown Feb 11, 2011

Take a look at the implementation of M_FREE_CONSOLE in be_machine.c

I'm wondering if this change will break free_console() when running from eui.exe but the app really wants to get rid of the console window (as you can no longer free it, if I understand the code correctly). I guess we could always say that the app in that case should have been run with euiw.exe but this is a change from the way earlier versions of Euphoria (and exwc.exe) worked.

Shawn left out the fixes part, he should have said * fixes 614 or * fixes ticket:614 in the commit message but didn't, so the auto ticket process didn't notice the commit.

9. Comment by mattlewis Feb 11, 2011

I've marked this as "Fixed, Please Confirm," which seems more appropriate than "New."

I don't think that would affect M_FREE_CONSOLE, though I suppose testing is the only way to really be sure.

10. Comment by ArthurCrump Feb 11, 2011

As far as I can see, Shawn's problem does not indicate a bug.
He is happy that running with eui text.ex the program returns without waiting for a key and that when running with euiw a window opens up and waits for a key.

When run by double clicking in explorer with the environment set up by the Euphoria installation, a file ending with .ex will be run with eui and a file ending in .exw will be run with euiw. Therefore, double clicking on text.ex will run with eui, so I would not expect it to wait for a key. That is why I suggested changing the name to text.exw to see what happened.

It is also possible to run test.ex with euiw by using right click and the option "open with..."

11. Comment by SDPringle Feb 13, 2011

I will never understand why it is desirable to some to have a black box flash on the screen and disappear. If you want that, just don't call maybe_any_key.

12. Comment by mattlewis Feb 14, 2011

This isn't about the automatic pause by euphoria, but a library routine that can be used by users as a convenience for the people using their program. We've been struggling about how to best implement this functionality, but I think Shawn finally got it right with this fix, though I haven't tested the behavior myself yet.

Search



Quick Links

User menu

Not signed in.

Misc Menu