Getting focus causes window to move to different line in program

[Scott R]

The typical scenario is this:
  > Working primarily on one program with one or more additional programs also open
  > Two or three windows open viewing different parts of the primary program
  > Usually one, sometimes two, windows open viewing parts of the other programs
     (with four 24" monitors a lot of windows can be open at one time)
The problem arises when changing focus from one window to another.
For example:
    Window "A" may be positioned on line 123 in program "A"
    Window "B" may be positioned on line 456 in program "A"
    Window "C" may be positioned on line 789 in program "A"
    Window "D" may be positioned on line 321 in program "B"
    Window "E" may be positioned on line 654 in program "C"
I switch from Window "B" to Window "E" using the mouse
I then switch back to Window "B" and the position in the program will:
    Maybe change to the first line
    Maybe change to the line being viewed in Window "A" or "C"
Sometimes Ctl-Z will reposition to the proper line, sometimes it may back out a change I don't want to back out.

It goes without saying, this is beyond annoying.



SlickEdit Version 15.0.1.3

Serial number: WB288996
Licensed number of users: Single user
License file: C:\Documents and Settings\All Users\Application Data\slickedit\15\slickedit.lic

Build Date: August 04, 2010
Emulation: CUA

OS: Windows XP
OS Version: 5.01.2600  Service Pack 3
Memory: 56% Load, 1185MB/2094MB Physical, 119MB/2097MB Virtual
Shell Info: C:\WINDOWS\system32\cmd.exe /q
Screen Size: 1920 x 1200

Project Type: Other
Language: .prg (dBASE)

Installation Directory: C:\Program Files\SlickEditV15.0.1.03\ (non-removable drive,NTFS,23843MB free)
Configuration Directory: C:\Documents and Settings\scottr\My Documents\My SlickEdit Config\15.0.1\ (non-removable drive,NTFS,23843MB free)
Spill File: C:\Documents and Settings\scottr\Local Settings\Temp\$slk.0 (non-removable drive,NTFS,23843MB free)

Hotfixes:
C:\Documents and Settings\scottr\My Documents\My SlickEdit Config\15.0.1\hotfixes\hotfix_loader_se15013_3.zip (Revision: 3)
C:\Documents and Settings\scottr\My Documents\My SlickEdit Config\15.0.1\hotfixes\hotfix_se1501_3_cumulative.zip (Revision: 3)

[hs2]

Seems that this is the same issue. - HS2

[Graeme]

I'm using 15.0.2, rather than 15.0.3 but I can't reproduce this problem, either with one file per window or multiple files per window option set.

When you say you switch from window B to window E using the mouse, what exactly do you do  - do you click somewhere in the window E edit window?  When you switch back to window B exactly how do you do that?

When you switch from window B to window E, is the cursor/caret position visible in window B before you switch or has the window been scrolled so that the "caret position" is not visible.

Here's a macro that does a non destructive undo - you could bind it to Alt Z or something.  It only un-does cursor movement and if you use it twice, it does nothing (much) the second time.

Code: [Select]

// undo only cursor movements
_command void xundo() name_info(','VSARG2_READ_ONLY|VSARG2_REQUIRES_EDITORCTL)
{
   int line = p_line;
   int col = p_col;
   cursor_right();
   if (p_line == line && p_col == col) {
      top();
      if (p_line == line && p_col == col) {
         bottom();
      }
   }
   if (undo_cursor() != CURSOR_MOVEMENT_UNDONE)
      _message_box("WARNING - check status line for undo message");
}

Graeme

Edit : also, how often does it do the wrong thing and does it make any difference if you do nothing when you're in window E.

[Scott R]

The macro you passed along works which is better than nothing.
I just loaded three source files to answer your questions, sort of:
    A) It doesn't matter if I make any changes in the source files.
    B) I used the mouse to navigate back and forth.
        1) It didn't matter if I positioned the cursor in the text window, or on the title bar, the unwanted line change occurred.
        2) The unwanted change was very consistent.
    C) In my test I had the following windows:
        A) Program #1
        B) Program #1
        C) Program #1
        D) Program #2
        E) Program #2
        F) Program #2
        G) Program #3
1. Start in "C"
2. Use either the mouse or keyboard to scroll down to another line
3. Didn't make any difference if I made a change to the line or didn't
4. Use either the mouse or Ctl-F6 to go to any other window than A B or C, say "E"
5. Doesn't matter if I make a change in the new window or don't
6. Use either the mouse or Ctl-F6 to return to "C"
7. The line position in "C" returns to where I was in step 1.
Some times there are little variations such as
1. Start in "C"
2. Change to different line.
3. Switch to "A" - no change in line position
4. Switch back to "C" and no change in line position.
5. Switch to "B" and no change in line position
6. Switch to "E"
7. Switch to "A" and it is positioned to the line number from step 1. (even though this is a different window).

And, there you have it - ad nauseam.
     
   

[Graeme]

I thought the "little variations" were the main problem.  You didn't mention the "7. The line position in "C" returns to where I was in step 1" scenario in your first post.  Does this happen every time except when there is a "little variation"?

Regarding   "2. Use either the mouse or keyboard to scroll down to another line."

This description is not exact enough.  I can't tell what you actually did.  "scroll" usually implies that the scroll bar moves and the number of the line at the top of the window changes.

When you used the mouse, did you just simply click on another line without the window scrolling at all?
When you used the keyboard, what actual keys did you press and did the window scroll at all?

I don't use multiple monitors.  Do you have slick maximized over all four monitors?  Does it make any difference if you
constrain slick to just one monitor.

What is Ctrl-F6 bound to?
In the second set of steps 1 to 7, does "6. Switch to E" actually mean "click the mouse in edit window E"?

Graeme

[Scott R]

I thought the "little variations" were the main problem.  You didn't mention the "7. The line position in "C" returns to where I was in step 1" scenario in your first post.  Does this happen every time except when there is a "little variation"?

Regarding   "2. Use either the mouse or keyboard to scroll down to another line."

>This description is not exact enough.  I can't tell what you actually did.  "scroll" usually implies that the scroll bar moves and the number of >the line at the top of the window changes.
One time I positioned the cursor in the window and used the scroll button to reposition.
Another time I positioned cursor in the window, clicked LMB, and used the keyboard arrows to reposition.
Another time I simply moved the scroll bar down, same result as using the mouse or keyboard.
FWIW, the scroll bar does move when repositioning using either mouse or keyboard.

>When you used the mouse, did you just simply click on another line without the window scrolling at all?
>When you used the keyboard, what actual keys did you press and did the window scroll at all?
Some time I did click on a line without the window scrolling at all.  When returning to the window the current line would revert to where it was before I left the window.
When using the keyboard I used the UP/DOWN cursor arrows.
Interestingly, if I double clicked on a word and selected it, then went to another window, then returned to the original window all text from where I did the selection to the original position is selected.


>I don't use multiple monitors.  Do you have slick maximized over all four monitors?  Does it make any difference if you
>constrain slick to just one monitor.
When I maximized Slick on one monitor the results were the same.  Multiple monitors don't seem to be a factor.


>What is Ctrl-F6 bound to?
Standard mapping "Go to next window".  Using the menu Window/Go to next window has same result.
I might add CTL+SHIFT+F6 has same results, whether I use the keybaord or the menus.

>In the second set of steps 1 to 7, does "6. Switch to E" actually mean "click the mouse in edit window E"?
Yes

Graeme

[Graeme]

>This description is not exact enough.  I can't tell what you actually did.  "scroll" usually implies that the scroll bar moves and the number of >the line at the top of the window changes.
One time I positioned the cursor in the window and used the scroll button to reposition.
Another time I positioned cursor in the window, clicked LMB, and used the keyboard arrows to reposition.
Another time I simply moved the scroll bar down, same result as using the mouse or keyboard.
FWIW, the scroll bar does move when repositioning using either mouse or keyboard.

Well I must be thick because I still can't tell what you actually did.

> One time I positioned the cursor in the window and used the scroll button to reposition.

What does "position the cursor in the window" mean?  Using the scroll button doesn't change the line number the cursor is on.

> Another time I positioned cursor in the window, clicked LMB, and used the keyboard arrows to reposition.

Why would that cause the window to scroll?

> Another time I simply moved the scroll bar down, same result as using the mouse or keyboard.

Moving the scrollbar doesn't change the line number the cursor is on.

Some time I did click on a line without the window scrolling at all.  When returning to the window the current line would revert to where it was before I left the window.

Are you saying that if the window doesn't scroll, you don't have a problem?

e.g. if you have
        A) Program #1
        B) Program #1
        C) Program #1
        D) Program #2
        E) Program #2
        F) Program #2
        G) Program #3

1. The cursor in window E is at line 50.  The cursor in window A is at line 100, window B at line 150, window C at line 200
2. Click the mouse in window C with the cursor on line 100 and in the centre of the window
3. Use down arrow to move the cursor to line 101 with no scrolling of the window.
4. Click the mouse on window E.
5. Click the mouse on window C.

If you follow steps 1 to 5 above, does that ever go wrong for you?  If not, can you carefully modify steps 1 to 5 above to give a reproducible procedure that allows me (or anyone) to try and do what you're doing, without any scrolling of the window.

How often does one of the "little variations" happen where the line number changes to a line number from some other window that's looking at the same file?

Graeme

[Scott R]

I am going to be out of the office for the next 1-1/2 weeks and unfortunately won't have much, if any, time for follow up.  Hopefully someone can make sense out of my description(s) of what I was doing.  For me the problem is easily reproducible, consistent, persistent, and resistant to work arounds.

The problem seems very similar to http://community.slickedit.com/index.php?topic=3082.msg12736  pointed  out by h2.  Scanning through that thread I notice a comments that the behavior was standard Slickedit scrolling behavior, annoying at times, but maybe handy.  They also said if you established a cursor position by doing something. 

One comment from that thread is pertinent:

This scrolling behavior is what happens with me also.  I always thought that this is the standard behavior, so I never gave it much thought.   It would be nice to have SE remember the 'scrolled' position rather than the 'cursor' position, but it's only a small inconvenience.  I've just gotten in the habit of clicking on the page before looking at a different document to 'mark' my spot when I return to that document.

Doing this doesn't work for me.  I can actually make a code change in a window displaying program "A", go to another window displaying program "B" , return to the window displaying program "A", where the code change was made, and the window will position itself away from the change I had just made.

Sorry there isn't much more I can add for the time being.  Suffice to say, Slickedit is losing track of the cursor position when moving between different windows that are viewing different source files.

[Graeme]

Doing this doesn't work for me.  I can actually make a code change in a window displaying program "A", go to another window displaying program "B" , return to the window displaying program "A", where the code change was made, and the window will position itself away from the change I had just made.

If this problem is as consistent and reproducible as you say, and you want it solved, then I suggest you try again to provide some clear detailed instructions on how to reproduce it that leave no room for guessing what you actually did.

The replies you've given to me so far seem inconsistent and confusing, for example, at no stage until now have you mentioned making code changes and in the sentence above, you don't make any mention of whether you scrolled the window or not.

Graeme

[Scott R]

We're having a communications problem.  I suggest that you turn this over to another set of eyes.  Sorry.

[chrisant]

@Scott R:  Can you reproduce the problem in a stock install with a fresh config?

I wonder if you have a custom macro innocently doing something similar to what I did.  See here for details.  The save_pos/restore_pos and _save_pos2/_restore_pos2 functions do not save or restore the scroll state.  So if a macro saves, then calls any function that directly or indirectly exits scroll, and then restores:  the scroll state is not restored, which can result in the vertical scroll position changing.

I can't tell if you're saying the cursor line actually changes, or if just the scroll position changes.  If the cursor line is changing, then there are some similar sequences of calls that can result in a macro accidentally changing the cursor line when it didn't intend to.

I can't follow what you did, the description is vague and abstract.  Concrete details would be helpful.  If you're a developer, then aim for the kind of repro steps that you like to see when a tester files a bug against your code.

Another time I simply moved the scroll bar down, same result as using the mouse or keyboard.

What does the first clause mean?  Do you mean you clicked on the scroll thumb, and dragged it down 1/2 an inch?
What does the second clause mean?  Do you mean that doing that step, plus some unspecified steps achieves the same result as doing some other unspecified steps that involved the keyboard?  I wish I could see over your shoulder, I don't know what these steps are.

FWIW, the scroll bar does move when repositioning using either mouse or keyboard.

I don't know what that means.  Do you mean that if you start at the bottom of a file and the scroll thumb is at the bottom of the scrollbar, and then you hold down the keyboard Up arrow and scroll all the way to the top of the file, that the scroll thumb stays at the bottom of the scrollbar instead of moving to the top?

B) I used the mouse to navigate back and forth.

Used the mouse how, exactly?  I must not be using the mouse the same way you do.  Sorry, I'm lost trying to follow the description of how to reproduce the problem.

Suggestion:
Can you pick one specific way to hit the problem?  Try it in a stock install with a fresh config.  If it occurs, write detailed repro steps for it.  If it doesn't occur, then either start checking your macros, or start adding config options until it starts to repro again.

[Scott R]

I'm on the way to the airport but will try to followup in the next two weeks since I have Slickedit installed on my laptop.  And then, if my wife has other plans while we're away - see you in two weeks.

[Scott R]

Well, upon my return to the office I sat down with this problem to document it.  In the process it became painfully obvious V15. 0.1.3 is unworkable and I am reverting to V14.0.2.2. 

I opened a support case so hopefully this problem will be resolved.  I can probably count on my fingers (of one hand) the number of times I have had to fall back to a previous version of anything in my forty year career.

[ScottW, VP of Dev]

Scott R, when you say that you have two or three windows open, are these windows within a single instance of SlickEdit or different SlickEdit windows (launched with the +new command line switch)?

What is your setting for Tools > Options > Editing > Editor Windows > Files per window?
Do you have "Place cursor on focus click" set to True or False (same options page as above)?
Are you getting this same behavior in a default config (useful to help us rule out problems introduced by custom macros or different settings)?

[Scott R]

Scott:

The windows are open within a single instance of SlickEdit.  FWIW, running multiple instances of SlickEdit never seemed necessary and possibly fraught with problems, so I've never done it.

This is an interesting set of options I have never visited before. 
The Tools>Options>Editing settings are:

  Files per window:             One file per window
  Smart next window style:      Smart next window
  Place cursor on focus click:  False
  New file tab position:        New files on right
  Abbreviate file tab captions: False
  New window width:             Default
  Custom window width:          0
  New window height:            Default
  Custom window height:         0

I have not tried reinstalling SlickEditso can't say it is a default installation because prior installations existed on my desktop computer.  OTOH, I did install it on my laptop which was a new installation of Windows-7 and did not have any prior installations of SlickEdit that might have carried forward custom settings.  The only macros I change are in vusrmacs.e with all the macros being pretty lame, mostly inserting text except for one that locates the next modified line.

BTW, I was able to FTP most of my configuration information to ftp.slickedit.com.