New edit windows open outside the desktop editing area?

[rkennett]

Using 15.0.0.6 and Ubuntu 9.10, settings one-file-per-window; when I open a new window by double-clicking in the project window, or a search result, or reference, etc, the new windows open progressive further 'up' the desktop so that the top bar is off screen (so there is nothing to grab to drag the window back onto the desktop). After a while the windows are completely off the desktop.

At this point I have to click "window->cascade" after every open to see the file, which is a real PITA.

If I exit SlickEdit and restart, the behavior goes back to normal for a while (new windows open at the top of the desktop and slightly right of the previously opened file).

I have 5 or 6 other versions of SE and none of them ever did this, nor can I find any way to change the behavior.

Anyone have any ideas?

[Graeme]

If you don't get a better answer you could try the code below - it's completely untested.  Any macro function whose name starts with _buffer_add gets called when a new buffer is created. "say" is a debug function - you can comment it once the code is working - and uncomment the call to SetWindow.  To start with you could just check what x and y coordinates ate turning up - then you might be able to check for negative values to determine when you need to re-position the window.

To load the code, open vusermac.e from your configuration folder, insert the code and load it using "load module" on the macro menu.

Code: [Select]

#include "slick.sh"
void _buffer_add_set_window_pos(int buf_id,_str buf_name,int buf_flags = 0)
{
   int x,y,w,h;
   _mdi.p_child._MDIChildGetWindow(x,y,w,h);

   say('new buffer ' :+ buf_name :+ ' ' :+ x :+ ' ' :+ y);
   //_mdi.p_child._MDIChildSetWindow(100,100,w,h);
}

You might get some ideas from here too
http://community.slickedit.com/index.php?topic=3671.0

[ScottW, VP of Dev]

How many monitors are you using? What is the size of each monitor? If you have more than one monitor, what is the arrangement of the monitors and does this occur on both monitors or just one?

Something is definitely weird, here. The new windows should open slightly lower and slightly to the right. When the new position would cause the window to be too low, the next one is opened at the top of the editor pane. When the new window would open too far to the right, the new window is placed at the left edge of the editor pane.

[rkennett]

Hi ScottW, nothing even interesting for monitor setup. A single Dell G2410 monitor, 1920x1080, NVidea GeForce GT 220, driver version 185.18.36.

What I find strange is that it (sort of) works on startup, then at some random point starts opening the windows high and to the right. The "sort of" is that when new windows arent off the screen, they dont get progressively lower, just move to the right. Other versions of SE act exactly as you say.

I did change the tools->options new-window-width and -height to "custom" and specified 800x480. The defaults for wide-screen monitors always drive me nuts :-) My SE12/Win on that station uses dual 24 widescreens and sometimes I stretch SE across both -  new windows default to something like 3500x400 <grin>

I havent tried Graeme's suggestion yet BTW

[rkennett]

I tried Graeme's suggestion (THANKS GRAEME!!!) and got this:

00001 new buffer /home/glm/Projects/ptdev.chris/ptdev/rkctshell/cpn/CPN_svc.c 0 0
00002 new buffer /home/glm/Projects/ptdev.chris/ptdev/rkctshell/cpn/CPN_shell.c 18 0
00003 new buffer /home/glm/Projects/ptdev.chris/ptdev/rkctshell/cpn/CPN_tstree.c 36 0
00004 new buffer /home/glm/Projects/ptdev.chris/ptdev/rkctshell/dbase/DBS_fileio.c 54 0
00005 new buffer /home/glm/Projects/ptdev.chris/ptdev/rkctshell/adc/adc08D1500.c 72 0
00006 new buffer /home/glm/Projects/ptdev.chris/ptdev/rkctshell/utils/GN_background.c 108 -138
00007 new buffer /home/glm/Projects/ptdev.chris/ptdev/rkctshell/dbase/DBS_capture.c 126 -276
00008 new buffer /home/glm/Projects/ptdev.chris/ptdev/rkctshell/ddr/captSem.c 144 -414
00009 new buffer /home/glm/Projects/ptdev.chris/ptdev/rkctshell/RT32/DmaDSPA.asm 162 -552
00010 new buffer /home/glm/Projects/ptdev.chris/ptdev/rkctshell/mx/DL_obj.c 180 -690

Not to state the obvious but the negative numbers appear wrong to me :-)

Here's the code I ended up with using after much pulling of hair and googling... one of the validity checks needs to run to prevent a "This property or method is not allowed on this object" error.

#include "slick.sh"
void _buffer_add_set_window_pos(int buf_id,_str buf_name,int buf_flags = 0)
{
   int x=0,y=0,w=1,h=1;

   if (_no_child_windows()) {
      return;
   }

   if (_mdi.p_child.p_window_state :!= 'N')
   {
      message('This operation is only supported on normalized windows.');
      return;
   }

   _mdi.p_child._MDIChildGetWindow(x,y,w,h);

   say('new buffer ' :+ buf_name :+ ' ' :+ x :+ ' ' :+ y);
   //_mdi.p_child._MDIChildSetWindow(100,100,w,h);
}

I'll try checking for a negative value and clearing it.

[Sandra]

Could you try something for me?  I think I might know where the problem is, but I'd like you to run a command and then tell me what your results are.

Paste the following command into a slick-c file.  Load the file, and then run the command "getInfo."  A debug window titled vsapi.dll should pop up with some info.  You should be able to click in the window, then hit Ctrl+C to copy everything in it (without highlighting).  Then paste the info back here.

Code: [Select]

_command void getInfo() name_info(',')
{ 
   say('x vert scroll = 'GetSystemMetrics(VSM_CXVSCROLL));
   say('x dlg frame = 'GetSystemMetrics(VSM_CXDLGFRAME));
   say('y caption = 'GetSystemMetrics(VSM_CYCAPTION));
   say('y dlg frame = 'GetSystemMetrics(VSM_CYDLGFRAME));
}
Thanks!

[rkennett]

Its not going to cooperate by showing the problem right now :-)  I still havent been able to isolate the trigger that starts the problem. For now here is the output though:

00012 new buffer /home/glm/.slickedit/15.0.0/vusermac.e 108 0 800 480
00013 x vert scroll = 18
00014 x dlg frame = 0
00015 y caption = 0
00016 y dlg frame = 0
00017 new buffer /home/glm/Projects/ptdev.chris/ptdev/cngmdi/utils/GN_memobj.c 126 0 800 480

I'll repost when it starts happening again. BTW its linux so I run VS from a command prompt and get the output there. I assume thats the right way...

[rkennett]

Forgot to mention... the macro to override the y location works pretty well. But. I've seen two instances where the window opens and it just plain isnt visible. The adjust macro apparently fails the checks for _no_child_windows() or _mdi.p_child.p_window_state :!= 'N' since opening the buffer doesnt display any results or correct the position. Cascading fixes the position, and exiting/restarting restores proper operation. This happens much less often than the negative y window location.

Also the negative y offset changes over time, and generally gets larger.

Almost seems like a plain old memory corruption bug but thats just a swag :-)

(Also forgot to say "Thanks!" for all the help!)

[rkennett]

Here is the update output when the negative #'s show up:

00041 new buffer /home/glm/Projects/ptdev.chris/ptdev/cngmdi/include/dbase/DBS_capture.h 486 0 800 480
00042 new buffer /home/glm/Projects/ptdev.chris/ptdev/rkctshell/include/dbase/DBS_capture.h 522 -251 800 229
00043 new buffer /home/glm/Projects/ptdev.chris/ptdev/cngmdi/dbase/DBS_shell.c 540 -251 800 480
00044 new buffer /home/glm/Projects/ptdev.chris/ptdev/cngmdi/sifc/TS_top.c 558 -251 800 480
00045 new buffer /home/glm/Projects/ptdev.chris/ptdev/rkctshell/gps/LOG_obj.c 38 22 759 478
00046 x vert scroll = 18
00047 x dlg frame = 0
00048 y caption = 0
00049 y dlg frame = 0
00050 new buffer /home/glm/Projects/ptdev.chris/ptdev/cngmdi/cpl/CPP_svc.c 576 -251 800 480
00051 new buffer /home/glm/Projects/ptdev.chris/ptdev/rkctshell/include/sect/SCT_extcode.h 594 -251 800 480
00052 x vert scroll = 18
00053 x dlg frame = 0
00054 y caption = 0
00055 y dlg frame = 0

[Sandra]

Well, your output looks to be exactly what I would expect of a normal situation, so I'm not sure what the problem is.

One thing I did notice from your output.  The problem seemed to happen for the first time on this line:

00042 new buffer /home/glm/Projects/ptdev.chris/ptdev/rkctshell/include/dbase/DBS_capture.h 522 -251 800 229

That file has the same name, but different path, of the file before it.  After restarting SlickEdit, can you get the problem to happen after opening two files of the same name?

I'm just following any sort of lead at this point.  It may be that I have to send you another executable which outputs some debug messages, but I'm trying to avoid that.

[rkennett]

Well, heres my guess... its not editing the same file name but thats a clue. What I think I was doing was opening the file, selecting some text and searching all files for that text, and opening that file from the search results window. I just tried all manner of sequences, and it started as soon as I searched all files for something and opened a new buffer from the results window.

That narrow it down any?

[Sandra]

Is this a reproducible case?  If you start up SlickEdit, the problem does not occur.  But then when you do a Find in Files and newly open a file by double-clicking in the Search Results window, that file opens up outside the editing area?

If that's the case, I will try to reproduce that scenario here.  We've tried to reproduce it on several machines, but I don't think we've tried opening things from the Search Results window.

[rkennett]

(sigh) Its not consistent. I cant find a specific sequence that reproduces it in a predictable way. I just tried from a clean start and I did a search/open and worked fine. Then a bunch of opens, then more search/opens, still fine. Then search references, open, search files, open, and *boom*. It was on the 11th buffer open.

It seems the search/open is the last straw, but there has to be some intermediate activity with the tags database. Or it may just be susceptible after 11 opens :-)