SlickEdit Community
SlickEdit Product Discussion => SlickEdit® => Topic started by: smartin on August 07, 2013, 01:58:01 PM
-
Hi,
I don't know whether I am the only one seeing this, but as far as I can see there is no rhyme nor reason to the order in which Ctrl-Tab will cycle through the editor windows.
In the options I have smart order enabled, on previous versions this gave me and MRU (Most Recently Used) list to cycle through, ideal switching between .c/.h files, things like that. Now I can more or less guarantee that I won't go to the tab I want, and I can't actually see what SlickEdit is trying to do. Last night I had 3 windows open, editing 2, one for reference, Ctrl-. to look at a prototype, Ctrl-, back to editing, Ctrl-Tab wrong window, grab mouse, select Window, etc. This is really bugging me now, and slowing me down greatly.
Maybe it is just my understanding of what is happening here, or maybe there is an option to go back to how it worked before.
Any help would be appreciated.
Regards.
-
Files per window: One file per window
Smart next window style: Smart next window
Scenario: File windows open are: A, B, C
#1 Next window ordering: A, B, C
#2 Current window: A
#3 Ctrl+Tab: switches to B (note that we are NOT pressing and holding Ctrl)
#4 Ctrl+Tab: switches back to A
#5 Perform Ctrl+Dot that switches to C
#6 Perform Ctrl+Comma that switches back to A
#7 Ctrl+Tab: switches to C
#8 Ctrl+Tab: switches to A
The above scenario is correct behavior, with the specified options settings, since window ordering depends on edit window focus.
Caveat: There appears to be a bug in v17 on Windows where #5 would not update the next window ordering. This was fixed in v18.
Caveat: There was a bug in v17 on UNIX and Mac where MDI window reordering was broken. This was fixed in v18.
If I have not described your scenario, then please provide detailed steps to reproduce. Thanks.
++rodney
-
Thanks Rodney,
Your example on how to order things was what I needed. The sequence you put in your example is what the current version of SlickEdit does, but it is not what I expect.
After analysing what is happening what I expect is a straight MRU, and this what previous versions of SlickEdit gave me.
Here are some sequences and what I think should happen.
#1 Let's have A, B and C open in that order, A selected.
#2 Ctrl-Tab activates B
#3 Ctrl-Tab activates A, so far so hoopy
#4 Open file D
#5 Ctrl-Tab now now takes you to B, not A.
Next sequence (your example):
#1 Let's have A, B and C open in that order, A selected.
#2 Ctrl-Tab activates B
#3 Ctrl-Tab activates A, so far so hoopy
#4 Ctrl-. activates C
#5 Ctrl-, activates A
#6 Ctrl-Tab activates B, when the most recently used file was C
Next sequence:
#1 Let's have A, B, C and D open in that order, A selected.
#2 Ctrl-Tab activates B
#3 Ctrl-Tab activates A, so far so hoopy
#4 Ctrl-. activates C
#5 Click on D
#6 Ctrl-, activates A
#7 Ctrl-Tab activates B, when the MRU file as D
I can continue....
Regards.
-
Evolution of my understanding of your description:
First read: What?! ;)
Second read: You only want window order affected when you deliberately select a window (e.g. by clicking on a Tab). Nope, your third example contradicts that.
Third read: You simply do not want your windows reordered. Ever. But you want Ctrl+Tab to toggle using the "Smart" algorithm (Ctrl+Tab from A-to-B, Ctrl+Tab from B-to-A). Note that the Smart algorithm is accomplished by reordering the windows.
The short answer is that we do not support what you are looking for. The behavior you enjoyed was actually a bug. You could try setting your "Smart next window style" option to "No window reordering" and see if you can live with it, but you won't get the Ctrl+Tab behavior (I think) you want.
The second idea I had (only changing window order when deliberately selecting a window) is something I could understand wanting (maybe), but it is not what you are looking for.
If anybody else would like to chime in on this, please feel free.
++rodney
-
Thanks Rodney,
What I would really like would be MRU, always go to the last active window. I did try no reordering and that was more understandable, but still not usable. Seems like the smart window reordering is way too smart for me. ;D
Regards.
-
Thanks Rodney,
What I would really like would be MRU, always go to the last active window. I did try no reordering and that was more understandable, but still not usable. Seems like the smart window reordering is way too smart for me. ;D
Regards.
+1
This was the behavior before v18. The ordering is my biggest gripe of v18. I agree with smartin and this is an annoying point for me with v18.
-
Just to confuse things further, I found that "Smart next window" behavior only works when using next-window bound to Ctrl-Tab. If you bind next-window to another key, you get strict next-window traversal. This should at least be mentioned in the help, if not fixed.
-
Wow, I never would have thought that binding next-window to a different key would make a difference, but you're right. I have next-window bound to alt-right-arrow with smart-next-window set, and when I hit alt-right-arrow, while continuing to hold down the alt key, Slickedit merely switches between two windows. It never cycles to other windows. This is no longer usable at all, to me.
-
Wow, I never would have thought that binding next-window to a different key would make a difference, but you're right. I have next-window bound to alt-right-arrow with smart-next-window set, and when I hit alt-right-arrow, while continuing to hold down the alt key, Slickedit merely switches between two windows. It never cycles to other windows. This is no longer usable at all, to me.
That is actually different than what I saw. I had next-window bound to both Ctrl-W and Ctrl-Tab, with SmartNextWindow enabled. When I used Ctrl-Tab I got the expeced (to me) behavior, which is described by Rodney below. When I used Ctrl-W it did not go back to the previously active window, it always went on to the next one (i.e. no reordering to put the previously active window next in the rotation).
-
Let me chime in with my $.02 worth. This is been driving me crazy the last couple days because the tab is never what I expect. I've been using SlickEdit for over a decade, and it's always produced exactly the behavior I want (which coincidently matches the behavior of every other program world). The new version is so annoying I'm tempted to go back to my old version of SlickEdit. I would like to have an option to have the behavior just exactly like it used to work in 2011.
Copying from an earlier message, here is the behavior that is making me craziest.
#1 Let's have A, B and C open in that order, A selected.
#2 Ctrl-Tab activates B
#3 Ctrl-Tab activates A, so far so hoopy
#4 Open file D
#5 Ctrl-Tab now now takes you to B, not A.
I do this all the time. I open a new file and want to look at it, then the obvious thing to do that is go back to the file I was just on – not some arbitrary file that I might've looked at five minutes ago.
Is there some way to restore the old behavior, short of writing my own Ctrl-Tab processor (or copying it from the old version of SlickEdit).
-
Hmm. Yes, you are correct - you should have been taken back to A in that case. I'll check it out.
++rodney
-
Hm ... wonder whether I should upgrade to V18 ?!?
My suggestion to Rodney is to file a change request because this affects many die-hard SE users, and you don't want to upset any part of your loyal customers.
-
This will be fixed in the next hotfix. If you would like to try it out beforehand, and you're comfortable modifying macro source, you can do the following:
1. Edit macros/window.e
2. Modify _donextWindowStyle() at around line 2248:
CHANGE:
final_wid._MDIReorder(orig_wid);
TO:
orig_wid._MDIReorder(final_wid);
3. Save and load macros/window.e (Macro>Load Module). You should see "Module(s) loaded" on the status line on success.
Thanks for the report!
++rodney
-
That works perfectly. Thanks man... was making me crazy.
-
I spoke too soon. That change doesn't seem to solve the problem, and in fact the code never gets called for a normal Ctrl-Tab. it still exhibits pretty random behavior when you open new files, or reopen existing files.
As far as I can tell, the only thing that actually works correctly is if you select another tab with the mouse. Suppose you have 6 windows open. With the mouse to select Tab 1, Tab2 then Ctrl-Tab. you go back and forth between tabs 1 and 2 correctly.
Now select another tab using the mouse, and control tab takes you back correctly.
No open a new file, and you control tab and you wind up selecting one of the other tabs at random. I can't seem to figure out which tablet is, except that it's the completely wrong tab.
You get the same results if you "open" a file that is Re: open, the selecting it's tab.
I'd really like to just get the behavior back from 2011, since that actually worked.
-
Well that's strange since that issue is exactly what I thought I fixed. Make sure you have "Smart next window" set for your Smart next window style under Options>Editing>Editor Windows. Are you sure you have the modified macro loaded?
++rodney
-
I made sure I have 'Smart next window' enabled, and also 'New files on right'
To test:
- I Edit File1, File2, File3, File4 in sequence.
- 4 Tabs open left to right as expected
- Edit window.e which becomes the fifth window
- Make suggested change and add some say() statements to be sure it's working. Load and run.
- Ctrl-Tab flips between File4 and Window.e as expected
- With window.e selected, hold Ctrl and cycle to File1
- Ctrl-Tab now switches between File1 and window.e as expected
- From File 1, hold Ctrl and navigate to File 3 and release Ctrl. Now Ctrl-Tab goes between File1 and File 3 as expected
- With the mouse, select File1 and then File4. Ctrl-Tab now toggles between File1 and File4 as expected
- With File1 selected, open a new file from the commandline. It opens in the right tab as expected.
- Ctrl-Tab now toggles between File4 and the new file, rather than File1
- Verified the new code is in place and executing when the new window is loading (via say)
- Opened a new window from a bookmark. It works as expected.
- Opened a new window via the e command. It works as expected.
- Opened a new window via Ctrl-O and it works as expected
This might explain why you don't have hordes in the street with pitchforks. The only use case that doesn't work is when you open a new file via the command line. Unfortunately, that's how I open about 90% of my files (I do it with hotkeys). It's probably an atypical usage patterns and most users probably didn't even notice the problem.
Now that I understand the problem I can probably make a hacky temporary solution involving calling vs with the -#e switch that will at least work for files without spaces. You can't quote the filename right for files with spaces though, so I'd need some other hack. I'm hoping that I can just wait til tomorrow and you'll have it all figured out anyway.
-
Could not reproduce on Windows.
Make sure your say() window is not popping up in the middle of all this. All bets are off if focus is switching to the say() window while Ctrl+Tabbing around.
Also: Are you using any third-party tools/window managers that would mess with application focus (e.g. WindowBlinds, etc.)?
-
It does it with and without the SAY statements. I'm not really doing anything funny with focus, not that it should matter. I have a _switchbuf that sets some options whenever I enter a window, but it doesn't do anything funny with windows.
Just to prove the issue, I did the following:
1. Renamed my 18.8.0 Config directory
2. Restarted VSlick and accepted all defaults so I have a new clean install
3. Verified that the Smart tabs are enabled
4. From a DOS Prompt, Execute
VS File1
VS File2
5. Now I have 2 tabs as expected and Ctrl-Tab switches between the two
4. Close all tabs and return to DOS and execute
VS File1
VS File2
VS File3
Each time I'm just Alt-Tabbing back to the command prompt to execute the command.
When it's done, Ctrl-Tab switches between File1 and File 3, instead of File2 and File 3 as expected (and as all previous VSlicks did, and as all other editors do).
5. I wrote a batch file that opens File1, File2, File3 in that order with a 1 second delay between, so I never change focus. That does the same behavior.
I think this shows it's clearly broken.
-
I only see the behavior you describe if I do *not* have the window.e fix loaded. Do you have the window.e fix loaded?
++rodney
-
I do but just to be double-sure, can you paste the actual fixed file so we're sure we're using the same thing. Use w zero 2 at wademan.com
-
You can download it from the following:
http://support.slickedit.com/outbound/wademan/window.e (http://support.slickedit.com/outbound/wademan/window.e)
++rodney
-
That does the job. Guess I didn't apply the patch right. Thanks Rodney.
-
Agreed. The patch helped a little.
For years, every now and then, VSE would offer up a random window on <ctrl><tab>. Sometimes this would be a file I haven't accessed in a VERY LONG time. It usually happened when cycling through the "file queue." I like to keep every file in my entire project open all the time. Sorry, that's just me. That means when I open file, I'll select a whole directory in the open dialog and never actually view that file. Sometimes the file presented when using multiple <ctrl><tab> hits (hold <ctrl> and multiple press <tab>) would be something I hadn't touched... maybe ever.
With the v18 upgrade, I now get random files every time I <ctrl><tab>.
I applied your patch and it helped a bit. As long as I only expect 1 file in history in the file queue, it's ok. Multiple hits and anything could happen.
-
Seems to me the rules should be simple for Smart Next Window, and maybe I'm just using the wrong value. If I view, modify, or even smell a file it should be pushed onto the front of the queue (and removed from its previous location.)
If I <ctrl><tab> I should get the last viewed/modified file.
If I <ctrl><tab><tab> I should get the one previous to that.
etc. and onward into infinity, in a circular method around the queue eventually coming back to the front.
Is this 'not' Smart Next Window? Am I just misunderstanding the rules?
This definitely isn't either of "Reorder Windows" or "No window reordering."
On this rule-set it seems any and every type of access should do this push to the queue: <ctrl>. <ctrl><shift>f <ctrl>, open drag-n-drop not-matter-what
The only question, to me, is whether to remove a file from the queue if it gets closed.
Currently, this is not what I know as Smart Next Window. What should I be using?
-
That's what I want, too. I started to try to write that support as a standalone macro a couple years ago (the request isn't a new one), but I don't have as much time for writing macros as I used to, and I didn't get very far.
-
Seems to me the rules should be simple for Smart Next Window, and maybe I'm just using the wrong value. If I view, modify, or even smell a file it should be pushed onto the front of the queue (and removed from its previous location.)
I'm not certain I understand you but my xretrace macro
http://community.slickedit.com/index.php/topic,4693.0.html (http://community.slickedit.com/index.php/topic,4693.0.html)
lets you retrace your steps according to where the cursor has been, but it also lets you retrace by "skipping" to the next buffer, which is probably not exactly what you want because you're likely to still visit the same buffer more than once. However, I do have another macro that I haven't tested on slick V18 that lets you "retrace" without re-visiting a buffer. I'll try and test on V18. It actually saves the visited buffer list per project on disk, if you configure it to.
-
I posted a new macro in the user-macros folder - it's a small amount of code that uses _switchbuf to keep track of the buffers visited. Instead of using _switchbuf it would be possible/easy to use the timer callback in my xretrace macro to detect when the current buffer has changed and maintain the list. I might add that to xretrace one of these days.
-
It looks like this fix didn't make it into 18.0.1. I just installed it, and it reverted to the broken behavior. I fixed it by loading Rodney's hot fix over the file in the default VSlick\Macros folder (http://support.slickedit.com/outbound/wademan/window.e), after verifying that the only differences were Rodney's missing hotfix.
-
I have verified that the fix is definitely in there. You can test this by launching the editor with a clean config.
++rodney
-
After nearly going crazy about SlickEdits random and totally unpredictable way to switch to the next tab or tab-window (Crl+Tab and Ctrl+N) I have just solved the problem for me.
All I need ist a predictable behaviour. As in Firefox or any other application that use tabs, Ctrl+Tab has to move to the next tab which is on the right side of the current tab. Regardless of any opening order and of any tab arrangement changes. Its that simple.
To accomplish this:
On SlickEdits command line: bind-to-key next-buff-tab : Ctrl+Tab, bind-to-key prev-buff-tab : Shift+Ctrl+Tab, bind-to-key next-tab-group : Alt+PgDn, bind-to-key prev-tab-group : Alt+PgUp. Of course you may choose any other keys.
Uri
-
Rodney, I know logic-wise your change may work, but for efficiency sake, could I suggest reworking the if statement to have a compound OR since the else if now has the same setting.
Here is your solution:
if ( _default_option(VSOPTION_NEXTWINDOWSTYLE) == 1 ) {
// Smart next window
//final_wid._MDIReorder(orig_wid);
orig_wid._MDIReorder(final_wid);
} else if ( _default_option(VSOPTION_NEXTWINDOWSTYLE) == 2 ){
// Reorder windows
orig_wid._MDIReorder(final_wid);
}
if (add_windowhist) {
_menu_a
Here is what I think the 'if' should be:
if ( _default_option(VSOPTION_NEXTWINDOWSTYLE) == 1 ||
_default_option(VSOPTION_NEXTWONDOWSTYLE) == 2) {
// Smart next window OR reorder windows
//final_wid._MDIReorder(orig_wid);
orig_wid._MDIReorder(final_wid);
}
if (add_windowhist) {
_menu_a
-
This is still a problem with V19, and in fact, the fix used in V18 does not work in V19.
-
This is still a problem with V19, and in fact, the fix used in V18 does not work in V19.
Agreed
-
Sorry this is broken. To reproduce the problem with a default config, "e A", "e B", click on document tab A, "e C", press Ctrl+Tab and A should be active but B is active instead. If this is the problem your are seeing this is definitely a bug which is reproducible in v18 and v19.
I haven't had time to check into this thoroughly but it seems that if I replace the v19 code with the v17 code (it's been refactored so you have to look at it carefully), it works.
Here's the fix for the _doNextWindowStyle function in window.e:
void _doNextWindowStyle(int final_wid,int orig_wid,boolean add_windowhist=false) {
if (final_wid!=VSWID_HIDDEN && orig_wid!=VSWID_HIDDEN &&
(_iswindow_valid(orig_wid) && orig_wid.p_mdi_child) &&
final_wid!=orig_wid) {
#if 1
// Copied from v17 code which seems to work
if (_default_option(VSOPTION_NEXTWINDOWSTYLE)==1) {
orig_wid._MDIReorder(final_wid);
} else if (_default_option(VSOPTION_NEXTWINDOWSTYLE)==2){
orig_wid._MDIReorder(final_wid,true);
}
#else
// old v19 code which appears be the problem
if (_default_option(VSOPTION_NEXTWINDOWSTYLE)==1) {
final_wid._MDIReorder(orig_wid);
} else if (_default_option(VSOPTION_NEXTWINDOWSTYLE)==0){
orig_wid._MDIReorder(final_wid);
}
#endif
if (add_windowhist) {
_menu_add_windowhist(final_wid);
}
}
}
Once we've had more time to check into this carefully, we will post update information.
-
I just registered in order to say that this bug makes v19 unusable for me and I had to go back to using v17 until it's fixed. My SlickEdit installation is on a shared drive on Linux (that I have no control over), so I can't go and edit the window.e file in the installation directory. My configuration directory is my own though, so I think a hotfix would be an option (since I think I noticed that hotfixes get applied to the configuration directory).
Can a fix for this issue be added to the cumulative hotfixes ASAP?
-
You can get 19.0.2 RC 4 right now and it has the fix in it. Any of the 19.0.2 RC's have this fixed.
-
Excellent, thank you!