Clears all default edit options after injecting about clink HOT 3 CLOSED

From [email protected] on July 14, 2012 10:54:34

What you are seeing in normal Windows behaviour and not related to the presence of clink.

A console window's properties can get set from multiple places. Either the global default properties, from the shortcut's properties, or possibly from a registry entry tied to the executable (I'm less certain about this last one). The shortcut/executable properties override the default ones if they exist.

If at any point you set a console window's current properties (not the default properties), Windows will save those properties with the shortcut/executable and use those properties instead of the default ones for future sessions.

Notice that in your repro steps you set default properties but check the window's properties to verify but as we've discussed, these properties may not have come from the default set. As such you can't compare default properties against current properties. Only tests of default/default and current/current are valid pre/post injection of clink.

Hope that clears things up at least a little. Windows' behaviour is quite strange and hard to explain clearly.

Status: Invalid

from clink.

From [email protected] on July 17, 2012 05:23:18

I would like to respectfully disagree on some points. Yes, Windows
behaviour is strange. Of this fact there is no debate.

I have a pre-existing shortcut that starts up cmd.exe with window, buffer
size, colors, (sorry - colours) etc., including QuickEdit enabled.

1. Close all cmd.exe windows, install clink, open the window from the
   shortcut, open "Properties" (not "defaults") and the QuickEdit checkbox is
   off. ALTHOUGH the QuickEdit mode does seem to be enabled - if I click
   & drag in the window it selects text.

2. Close the window (with no other property changes), uninstall clink, open
   the window from the shortcut, open Properties. The QuickEdit checkbox is
   set.

Empirical evidence kind of points to clink being involved here in some way,
although maybe not to the extent of the initial bug.

cheers & thanks. it is a fantastic addition to my tool set!!

jeff

from clink.

From [email protected] on July 22, 2012 05:55:36

I'm still unable to reproduce this. It would be great if you could boil the issue down to some explicit steps that exhibit different behaviour depending on whether clink is install or not. As I'm using Win7 which introduced a new way of handling console windows (conhost.exe) so it's possible this issue is specific to earlier versions of Windows.

While looking into this I found what I was trying to recall in my last comment about the registry. In Win7 at at least, Windows caches the properties for a console app shortcut in the registry by name. If you create another shortcut elsewhere with the same name it will use the cached properties. It also works if you delete the shortcut and recreate it with the same name.

This could perhaps be confusing so it's worth clearing out the cache if you're comfortable deleting keys from the registry (and this caching "feature" is present in Vista). The key in question is here;

HKEY_CURRENT_USER\Console

Great to hear you're finding clink useful!

from clink.