How do I get SlickEdit to create smaller windows

[adw2612]

My LInux system has a very large Xinerama setup with a virtual resolution of > 6k x 1200.
When I run slickedit across 2-3 displays, and I open a new window, SlickEdit chooses
a default size of about 2400x800... not very useable.  Is there a way to change the default
size of a newly opened window?

[SlickEdit Support]

Hi there,

Just an FYI for you.  There is a current Feature Request in place to allow for the control of initial window/buffer size.

Best,
SlickEdit Support

[PeterHouse]

I hate to be a pest on this but here I go . . .

I have requested this feature for over two years and two version releases (9->10->11).  What are your plans to include this feature in your product?  I also have a LARGE desktop area (1600x1200x3) and between the new window sizes and use of cascade require me to spend a large amount of time resizing windows to a little over 80 columns. 

Surely there must be some way to solve this easily.

Peter House

[Wanderer]

There might be an event you can hook -- _mdi_child_create_?, but I haven't found one yet.  This -- events and callbacks -- is a dark corner of SlickEdit...

[Phil Barila]

Feature requests?  They do get to work on some of them!
I've been sending them the following list each major release:

• Rich text on the clipboard.  It already prints in rich text, how hard can it be to copy it to the clipboard?
• Multi-row file tab bar.  I asked for that as soon as the file tab bar appeared.
• Button in the "Show info for symbol under mouse" popup to show me the definition of it.  If I've gone to the trouble of moving my mouse over the thing, I don't want to go back to the keyboard to Ctl+. it.

Well, in the latest 11.0.1 release, I got part of the third one.  There is a little green arrow that will take you to the prototype of a function, though it's not there for data types, like structs, yet.  But at least there is some progress here!

[SlickEdit Support]

Attached is a macro that you can use to control the size of the buffer on opening.  There is a slight, but noticeable, "blink" when you open a file because SlickEdit opens the file as it normally would and then the macro resizes the buffer for you.  (Is a blink a lesser evil than resizing the buffer with your mouse?)

1.)  Extract and Save the file to your Macros dir, or wherever it is that you keep your Macros.

2.)  The code for the 'resize' command is commented, so MAKE SURE you read it before you load it.  (Beginning comments describe that there are two ways that you can resize your edit buffers, so you will either need to make a Tools-->Options-->General option change or a change to the resize.e code depending on how you want the windows to be resized.)

3.) Load the files' macro code by going to Macro-->Load Module-->and navigate to the file.

Please remember that this NOT a SlickEdit supported macro but it should do the trick for you.  And you can always "unload" it via the Macro-->Unload Module dialog. (resize.ex)

Regards,
SlickEdit Support

[Tim Kemp]

This works great most of the time.  It blows up when you go to view references.  I'd go try to fix it, but a) I have done almost no SE scripting and b) I'm swamped with the work I'm getting paid to do.

Any idea how to limit it so that it doesn't try to resize non-document windows?

[Tim Kemp]

I finally got around to modifying this macro to not resize non-editor windows.  There is probably a more elegant way to do it, but this seems to work (so far anyway.)

- Tim

[Phil Barila]

Bump:  Is this still on the official feature request list?  I appreciate that Tim has modified the initial unsupported one provided by SlickEdit to mostly work, but I'd like to reiterate my desire for this to be a supported feature.  So much so that I would much prefer this to the windbg dll support I "me too"ed yesterday, if you had to make a decision between those two features.

[TxDot]

I also cast my vote for this to be a high priority feature. Even to the point of including it in the next update rather than wait for the next major release. 

[JeffB]

I agree.  This should be a priority in my book.

None of the scripts I've tried so far work without causing an error in some cases..which makes them all unusable.

Currently, I typically keep the SlickEdit window sized so that I can get two editor windows side-by-side.  I created "resize-window-left" and "resize-window-right" macros based on previously submitted macros and added buttons/keystrokes.  So i just click a toolbar button after opening new windows and the window gets put in one of the two spots I normally move windows to anyway.

This works fine for opening windows to edit, but when browsing/tracing through code, it's extra "work".   But it's better than a window that's always too wide, and never tall enough.

[alex]

JeffB, can't you just write something like this, using the "magic" prefix _buffer_add that's called when a new buffer is added?

int next_open_pos = 0;
void _buffer_add_set_new_window_size()
{
    if ( next_open_pos == 0 ) { resize_window_left(); next_open_pos = 1; } else { resize_window_right(); next_open_pos = 0; }
}

If that doesn't work in certain cases, it sounds like your resize macros have some issues.  Mine don't cause problems and look like this (note that I put my next_open_pos assignments in the resizing functions because I move windows around a lot):

_command resize_window_left() name_info(','VSARG2_MACRO|VSARG2_MARK|VSARG2_REQUIRES_MDI_EDITORCTL)
{
   if ( p_window_state == 'N' )
   {
      _macro('R',1);
      _move_window( 0, -1, 610, WINDOW_HEIGHT );
      next_open_pos = 1; 
   }
}

[Clark]

I'm looking into implementing something new to handle new window size for 12.0.2 and I would like some feed back.  There are two ways to do this. 

Method 1. The user specifies the pixel width and height of the window with a "set_new_window_size" command.  There could also be a unset_new_window_size command.

Method2.  The user specifies the number of lines and columns to be displayed.  There could still be a "set_new_window_size" command but the number of lines and columns are stored.  I don't think using the vertical line column make sense for this since it require the user to have a vertical line to get the window size feature.

I prefer to implement Method1 because it's implementation does not depend on the contents of the window.  Method2 would have to a assume normal text display and would only work well for fixed fonts.  For proportional fonts, the average character width would be used which won't be accurate.

[Phil Barila]

Clark, thanks for looking at it.  I use mono-spaced fonts uniformly, so I'd prefer to be able to specify rows and columns.  I guess I'm selfish that way.     Even if you end up making it a pixels x pixels window, instead of the way I want it, it's vastly superior to what we have now.  If it were up to me, and I know it isn't, I'd do the window size first, and then add a routine that would figure out the window size from the row/column/fontsize, and provide that, too.  Last one set wins, I guess, or the row/column applies to windows with fixed fonts, and the pixels applies to all the others.

[JeffB]

alex,

I'm using the resize.e macro that's been floating around for a while.  I've tried the original "_buffer_add_resize()" and "_buffer_add_set_new_window_size()".  Both cause an error (This property or method is not allowed on this object) when clicking on a function in the "references" listing the first time you do it.  I guess SlickEdit opens the file for previewing and hits the macro trying to move/resize it.

Do you not see errors under similar circumstances ?

-Jeff