Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.
 Entire forum ➜ MUSHclient ➜ General ➜ Has the input box behavior changed?

Has the input box behavior changed?

It is now over 60 days since the last post. This thread is closed.     Refresh page


Pages: 1 2  

Posted by Zeno   USA  (2,871 posts)  Bio
Date Thu 21 Aug 2008 08:47 PM (UTC)
Message
A friend DLed a new version of MUSHclient. He said the input box behavior has changed. He used to be able to type and it would enter the input box (even if the cursor wasn't there) and he was able to Ctrl+C.

He said the new version wouldn't let him type unless he put the cursor into the input box. If he turned on "All typing goes to input window" he can no longer Ctrl+C (which is correct).

So he DLed 3.42 and it went back to how it was (and what he likes);
Quote:
there
it works
text goes to box
and i can copy
phew
i knew i wasn't crazy
me: Is the cursor always in the input box?
Or does it go there when you start typing
Saint: goes there when i start typing
Sent at 4:42 PM on Thursday

Zeno McDohl,
Owner of Bleached InuYasha Galaxy
http://www.biyg.org
Top

Posted by Nick Gammon   Australia  (23,094 posts)  Bio   Forum Administrator
Date Reply #1 on Thu 21 Aug 2008 09:24 PM (UTC)
Message
I don't think there was ever a version that let you automatically put the focus in the command window, and also let you Ctrl+C to copy. However there is a plugin that you probably know of, that lets you use Ctrl+C, even if you have the "all typing goes to the command window" option set.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Zeno   USA  (2,871 posts)  Bio
Date Reply #2 on Thu 21 Aug 2008 10:02 PM (UTC)

Amended on Thu 21 Aug 2008 10:04 PM (UTC) by Zeno

Message
I just tested this myself. 3.42 does indeed automatically go to the input box once you start typing. I even had stuff highlighted in the output box and started typing, and it went to the input box while the stuff stayed highlighted (and I could Ctrl+C). I have no plugins installed.

It'd be great if this behavior was in the current version.

Zeno McDohl,
Owner of Bleached InuYasha Galaxy
http://www.biyg.org
Top

Posted by Zeno   USA  (2,871 posts)  Bio
Date Reply #3 on Wed 17 Sep 2008 06:51 PM (UTC)
Message
Can anyone else confirm this behavior in 3.42?

Zeno McDohl,
Owner of Bleached InuYasha Galaxy
http://www.biyg.org
Top

Posted by Loganpup   (2 posts)  Bio
Date Reply #4 on Thu 23 Oct 2008 05:30 AM (UTC)

Amended on Thu 23 Oct 2008 06:49 AM (UTC) by Loganpup

Message
Well, as Zeno just pointed me to from a similar thread in the bug reports forum, I too can confirm that behavior in 3.42. Now to grab the freeware regcode and downgrade.

Edit: I think I can verify that 4.01 also has the same behavior

Edit again: Or maybe not. 4.01 has all typing going to command window. It will copy output text if there's nothing highlighted in the command window, but I tend to leave "Keep commands on the prompt line" so that doesn't quite work.
Top

Posted by Nick Gammon   Australia  (23,094 posts)  Bio   Forum Administrator
Date Reply #5 on Fri 24 Oct 2008 05:28 AM (UTC)
Message
Well I have found 2 things different in the latest version(s) compared to 3.42.

First, in 3.42 the option "all typing goes to the command window", although present in Global Preferences, was not actually being tested, so effectively it was on, see code below:


void CMUSHView::OnChar(UINT nChar, UINT nRepCnt, UINT nFlags)
{

// if typing is received in top view, activate bottom view and pass character on

  OnKeysActivatecommandview ();
  m_bottomview->SendMessage(WM_CHAR, nChar, nRepCnt | (nFlags << 16));

  }



Second, although the test is now actually doing something, there is also a similar test on OnSysChar which wasn't present in 3.42. This appears to catch a keydown (eg. pressing Ctrl), so that the view is switched to the bottom view before you finish typing Ctrl+C, thus the copying won't work.


void CMUSHView::OnSysChar(UINT nChar, UINT nRepCnt, UINT nFlags)
{
	if (App.m_bAllTypingToCommandWindow) {
		OnKeysActivatecommandview();
		m_bottomview->SendMessage(WM_SYSCHAR, nChar, nRepCnt | (nFlags << 16));
	} else
		CView::OnSysChar(nChar, nRepCnt, nFlags);
}


The older version, which didn't do that, seems to process Ctrl+C in a more "natural" way. The only reason I can think of doing that though, was that under some situations, if the focus was in the output window, some keys would not work (eg. macro keys), although I am not too sure about that.

If you can confirm that the behaviour in version 3.42 is what you want (including testing other things like macro keys, accelerators etc.) then I can remove the function above (CMUSHView::OnSysChar) and everyone should be happy.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Worstje   Netherlands  (899 posts)  Bio
Date Reply #6 on Tue 17 Mar 2009 06:52 AM (UTC)
Message
Has this fix ever been tested and implemented?
Top

Posted by Nick Gammon   Australia  (23,094 posts)  Bio   Forum Administrator
Date Reply #7 on Thu 19 Mar 2009 09:01 PM (UTC)
Message
I tried it more recently (in time for the last release) and it seemed to not work any more. I am reluctant to fiddle too much with the code, as pulling out stuff that would make that work will probably make something else stop working.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Worstje   Netherlands  (899 posts)  Bio
Date Reply #8 on Thu 19 Mar 2009 11:04 PM (UTC)
Message
I don't have a debug/compilation environment, but I have dozen's of plugins and a fair amount of worlds with plenty of settings to test stuff with.

If you want, I can test any test versions you compile. It is a question people ask me a lot (I'm the local MUSHy guru usually) and something I'd really would love to see changed as it is one of MUSHclients more frustrating features for people.
Top

Posted by Nick Gammon   Australia  (23,094 posts)  Bio   Forum Administrator
Date Reply #9 on Sun 22 Mar 2009 08:27 PM (UTC)

Amended on Sun 22 Mar 2009 08:28 PM (UTC) by Nick Gammon

Message

Well, let's work through why it behaves that way so we can discuss the best way around it.

Each MUSHclient world has two main windows - the upper (output) window, and the lower (command) window.

Each window can have the "focus", which is where the problem starts. They both need to have the focus because both can have selected text, see image:

The relevant question here is, if I select Edit -> Copy or press Ctrl+C, what gets copied to the Clipboard? Is it:

  • "The illustrious Darkhaven Academy Headmistress"; or
  • "greet Mistress Tsythia"

The answer would seem to be "whichever window has the keyboard focus".

The problem is, if you select text in the upper window, with a view to copying it (and indeed after copying it), the focus is still in the upper window.

In early versions of MUSHclient, if you then started typing (eg. "north", "open door") your typing would be swallowed up because the upper window is an output window.

An early work-around was to make you press a key to return focus to the lower window. Both <tab> and <esc> were provided as handy and easy-to-hit methods.

In those versions, Ctrl+C worked in a "natural" way, however it was annoying if you clicked on MUSHclient to bring it to the front, by clicking on the output window (the larger one), and then found that what you typed had been thrown away.

Hence the invention of "all typing goes to the command window" was born. With this active, the program intercepted key events (like the letter "a") and before doing anything else, put the focus in the command window. Then the event was allowed to continue, with the focus now in the correct place.

At this point I think Ctrl+C still worked, because some keys are not, strictly speaking, characters (eg. F1 does not have a character equivalent, like "z" or something).

The inbuilt macros (like F2, F3, F4 etc.) worked because special provision was made for them. In the output window handlers were put in place for all the macro keys. These handlers set the focus to the command window, and then let the macro function normally.

I think the whole problem probably started around the time that you were allowed to make your own accelerator keys (with the Accelerator script function). Now it was possible to define key events (eg. Ctrl+Right-arrow) that do not generate character events, and thus did not shift the focus to the command window.

To work around this, the "all typing goes to the command window" functionality was altered to not just detect character events (like letters or numbers) but all keydown events. This fixed the problem with user-defined macros, because the moment you hit a key (like Ctrl) the focus shifted to the command window.

However this now caused the problem with the Ctrl+C, because as you type Ctrl+C the Ctrl key shifts the focus to the command window, and then by the time it has seen the "copy" command it copies from the command window and not the output window.

I developed a plugin a while ago that tried to work around that - if there was text selected in the output window, but not the command window, then Ctrl+C used the output window, otherwise it used the command window.

I'm not sure there is a better way. Maybe the functionality of that plugin could be incorporated into the client, but it would still depend on having text selected only in the output window.

Just changing things back to how they were is likely to bring screams of protest that user-defined accelerator keys "don't work sometimes".


- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Nick Gammon   Australia  (23,094 posts)  Bio   Forum Administrator
Date Reply #10 on Sun 22 Mar 2009 09:08 PM (UTC)
Message
One thing that might work is to change the way selecting works, so there is only ever one lot of selected text, as I gather the problem really relates to selections, and Ctrl+C.

It could work like this:


  • When you select text in the command window, any selected text in the output window is automatically deselected.

  • When you select text in the output window, any selected text in the command window is automatically deselected.


This isn't too bad, it is like treating the whole world window as a single block of text, and normally you only have one selection.

Then, when you hit Ctrl+C (or Edit -> Copy) it copies whatever selection there is (in either window), if any. This is similar behaviour to the current plugin.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Onoitsu2   USA  (248 posts)  Bio
Date Reply #11 on Mon 23 Mar 2009 01:47 AM (UTC)
Message
I like that functionality, only one selection is the best method of using the program, as most programs only allow one selection, so everyone is used to that functionality, new and seasoned uses alike.

If that were built into the client then, well there would be no plugin needed, and would probably run a little faster as it would be a hardcoded fix that is in the main memspace of the program.

-Onoitsu2
Top

Posted by Worstje   Netherlands  (899 posts)  Bio
Date Reply #12 on Tue 24 Mar 2009 10:37 AM (UTC)
Message
I dislike the plugin idea, since in my experience it tends to add newlines while I didn't select in a way one should be included, or the other way around.

I also dislike the only-one-selection-ever solution, since it is totally against my feeling of things. I can't really put it into words, tho. :/

You say the issue roots from passing the focus from one control to the other. Particularly the fact that you press Ctrl/Alt/Shift and it jumps away. Why not delay passing of focus until you know what the user wants to achieve in those cases?

Example 1: focus is on output window. I press Ctrl. Focus stays on output window. I press C. It sees it needs to copy and focus remains there.

Example 2: focus is on output window. I press Ctrl. Focus stays on output window. I press Q or something else that does not apply to the output window. Then it changes the focus and places the Ctrl and the newly pressed Q there for processing.

Essentially, only pass the focus once you know what is wanted. I imagine it is easy enough to check against the list of accelerators and built-in shortcuts, and there are no scripting provisions to fire on Ctrl/Alt/Shift being pressed.. so you should be reasonably safe with that method. Or am I missing something now?
Top

Posted by Onoitsu2   USA  (248 posts)  Bio
Date Reply #13 on Tue 24 Mar 2009 01:06 PM (UTC)
Message
What if a person wants to copy from the input area itself, that also needs to be a provision checked for.

If you are able to delay the focus passing then the solution is a simple fix, nice thinking Worstje.

Don't forget to force all pastes (CTRL + V) to focus in the input area first, or else well many coders would be mad if they could not paste code they've worked on, although you could send clipboard to server, but that does not leave it in the command buffer, which is the method I use on most occasions, as I can just scroll up, and make a simple tweak and then send it again.

-Onoitsu2
Top

Posted by Nick Gammon   Australia  (23,094 posts)  Bio   Forum Administrator
Date Reply #14 on Wed 25 Mar 2009 04:46 AM (UTC)
Message
Quote:

I press Ctrl. Focus stays on output window. I press C.


This is rather complicated, in particular because I don't handle that stuff right now, Windows does.

I'm not sure what the big deal is in having only one selection at once, after all that is generally the rule in most programs.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.


55,022 views.

This is page 1, subject is 2 pages long: 1 2  [Next page]

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum


[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.