Author Topic: Where did Maximizing Windows Option go?  (Read 7030 times)

Dan112123

  • Community Member
  • Posts: 44
  • Hero Points: 2
Where did Maximizing Windows Option go?
« on: April 08, 2009, 01:59:31 am »
in SE14 from help:

Maximizing and Minimizing Windows
By default, editor windows are floating when they are first opened. To specify that all editor windows should be maximized when they are first opened, from the main menu, choose Tools → Options → Editing → Editor Windows, set the option Maximize first window to True.

I go to that location and the option is not there. It used to be there - now it is gone. Ok now I'm nuking this POS release. If my employer knew that I spent all fudging day trying to get SE14 work they would fire me. This is unacceptable. You don't release software like this to the main public and I refuse to be your beta tester. I should probably look at VisualAssist again.

chrisant

  • Senior Community Member
  • Posts: 1410
  • Hero Points: 131
Re: Where did Maximizing Windows Option go?
« Reply #1 on: April 08, 2009, 02:17:58 am »
Did you know about the Search box in the Options dialog?  You can type "maximize" there and it will filter the list and find the option.

I understand venting anger, but you're not helpless.  :)

Graeme

  • Senior Community Member
  • Posts: 2432
  • Hero Points: 322
Re: Where did Maximizing Windows Option go?
« Reply #2 on: April 08, 2009, 05:14:59 am »
Did you know about the Search box in the Options dialog?  You can type "maximize" there and it will filter the list and find the option.

Out of curiosity I tried this and couldn't find the option  :)

From looking at _cbquit_MaxFirstWindow in bufftabs.e, it seems SE 2009 remembers the maximized state when you close the last buffer or editor and restores that state when you start up, so there's no longer an option to force the state at start-up, which seems reasonable  - but they forgot to remove it from the help file.

If anyone's desperate to get the previous functionality back, you can probably write a macro that gets executed at start-up and calls _default_option('F', true), after slick has done all its start-up stuff  - dunno how you do that though.

Graeme

chrisant

  • Senior Community Member
  • Posts: 1410
  • Hero Points: 131
Re: Where did Maximizing Windows Option go?
« Reply #3 on: April 08, 2009, 07:25:46 am »
Indeed, the Search in the Tools|Options dialog shows the option is gone.
So I used the Search in the forums, and ScottW explained here:
Quote
"...we made what seemed like a minor change after beta 4 to eliminate the "Maximize first window" option. We wanted to drive that setting off of the state of the last window to be closed..."
It was a last minute change, and updating the docs got missed.



The original post has some fair points, perhaps overstated a little.

@SlickTeam:  Stream of consciousness follows...

Syntax coloring is running into issues for some folks.  It might be related to performance tuning as covered in the "Performance Tuning" section in the Help, or it might be bugs in parsing specific syntax constructs, or it might be that the default settings are too expensive to warrant being defaults, or it might be something else.  Knowing that performance is going to be an issue, it would seem like either broader or more complex testing might be useful, or conservative default settings might be good.  For example, my employer requires special approval to interact with open source source code, but if the SlickTeam is not limited by such restrictions then it could be useful to download a lot of source files and write a little unit test macro that runs overnight and iteratively loads different files and times the cost of doing the symbol coloring on different parts of the files.  If a part takes longer than a small threshold, log the filename + line number range + time cost, and then analyze the logs the next day.  I don't know, maybe that's already been done, and real world usage has just turned up some unusual cases.

To piggyback on something JPorkka suggested in another post somewhere, it might be a good time to add some kind of Auto-Perf-Tuning smarts into the editor.  For example, brain storming off the top of my head:  There could be a Performance Dashboard in the Tools|Options dialog that presents useful performance analysis data.  The editor might keep track of how much time its spending on file access during idle (e.g. checking for modified files, etc etc), and if for a particular file IO rates are slower than some threshold then log it to be reported somehow in the dashboard.  Have a toolbar icon or status bar icon that lights up when there are performance alerts for the user to review.  Clicking the icon could open the Tools|Options|Performance Dashboard.  Now the editor is proactively helping improve configuration-based performance issues, and the feature is discoverable, and there is a central place for the editor to put perf-related settings and feedback.  Many of the things in the Performance Tuning topic in the Help can be either monitored or automatically configured.  Tag cache size is an interesting one:  Why not have an "Automatic Size" setting that dynamically uses up to 25% of the total RAM on the box, not to exceed 1GB?  Or something like that -- the idea being to dynamically tune the tag file cache size based on the tag files in use -- and if the tag files spill over the cache by some appreciable percentage then log that as a perf alert in the dashboard.  Could also be handy to see in the dashboard some basic statistics about SE's perf, e.g. breakdown of memory usage:  how much is used by the tag cache, how much is used by the undo stack, how much is used for normal buffers, how much is used by hidden buffers, how much is used by Slick-C.

Threading can help a lot, too, as has been discussed in another post.

Over the past year I've seen a number of reports in the forums about responsiveness.  Frequently it turns out to be idle time file access happening on foreground thread to check for changed files.  To solve that particular issue on Windows, the ideal solution is to use FindFirstChangeNotification and passively getting notifications about changed files rather than actively polling the disk, and when a change notification is encountered use a background thread to do the FileGetAttributes calls/etc to check if the editor should consider the files as having been changed.  Then set an event that the foreground thread is waiting on (MsgWaitForMultipleObjects), and the foreground thread can wake up and process a list of changed files that the background thread produced for it.  (Sorry, I don't know enough about other OSs to suggest optimal solutions on other OSs).

Another responsiveness issue used to be the time taken to populate the auto-complete popup windows, and I am extremely grateful to the SlickTeam for having implemented the new "Maximum response time for list parameters" setting in SE14 which has nailed that responsiveness issue!  8)

Quick testimonial:  With the combination of the "Performance Tuning" section in the Help, the removal of the FlushFileBuffers call, and the new "Maximum response time for list parameters" setting, SE14 doesn't randomly freeze anymore for me.  Excellent work SlickTeam!!

Of course now I'm eagerly awaiting further improvements (the reward for work well done is, of course, more work ;)).  The editor is moving in a great direction.  Sorry for the stream of consciousness, I hope some of it is useful.
« Last Edit: April 08, 2009, 07:30:59 am by chrisant »

ScottW, VP of Dev

  • Senior Community Member
  • Posts: 1471
  • Hero Points: 64
Re: Where did Maximizing Windows Option go?
« Reply #4 on: April 08, 2009, 02:57:04 pm »
@Dan112123: My apologies for the incovenience this has caused you. This small change wound up being a bit of a nightmare. Our goal was to make SlickEdit easier to configure by driving future actions off of past actions. If the last window closed was maximized it is very likely that you'll want to the next window opened to be maximized. Unfortunately, this change introduced a severe bug in our buffer management, which prompted us to pull the initial release shortly after posting it. And, as you have pointed out, we also missed the documentation change that goes with it.

Among others, the lesson here is that there are no "small" changes.

Symbol Coloring has been the most interesting aspect of this release. We discussed whether to turn in on by default and decided that it was the best way to let folks know that this very useful feature is there. We thought that existing users would see the difference in coloring, look at the User Guide to see what we've changed, and then configure the feature to their particular needs. Unfortunately, that's not how it played out for many people.

Though there are a few actual bugs in Symbol Coloring, the majority of the problems come from two sources: performance issues and inaccuracies highlighted by the coloring. A lot has already been said about the performance issues, and we appreciate the suggestions for how to improve it. In hind sight, a more moderate default scheme might have been a good idea. As for the inaccuracies, those are issues that have been in the tagging parsers in previous releases, but there was no way to see them. So, Symbol Coloring is helping us to make the parsers better.

Thanks for taking the time to let us know how you feel.

Dan112123

  • Community Member
  • Posts: 44
  • Hero Points: 2
Re: Where did Maximizing Windows Option go?
« Reply #5 on: April 08, 2009, 05:30:00 pm »
@Dan112123: My apologies for the incovenience this has caused you. This small change wound up being a bit of a nightmare. Our goal was to make SlickEdit easier to configure by driving future actions off of past actions.

Scott that's the problem, it does not memorize the window state for me. That's why I was looking for that option in the first place. I could take a video and demonstrate it. Maybe there is a bug in SE when it is used with -sc command? I lunch it like this

%__utils_path%\..\se\win\vs.exe -sc %__utils_path%\..\se\config %2 %3 %4 %5 %6 %7

BTW thre is another bug with backups. Eventhough I tell SE to use %__utils_path%\..\se\config slick edit is still trying to (be default) backup my user files to c:\program files\slickedit\backup. This directory doesn't exist on my computer. So every time I close it it crashes. And this is another bug in a long stream of bugs in this release. Now I hope you understand my frustration. It is not because of one single bug (symbol coloring) it's bugs all over the place that affected me greatly.



ScottW, VP of Dev

  • Senior Community Member
  • Posts: 1471
  • Hero Points: 64
Re: Where did Maximizing Windows Option go?
« Reply #6 on: April 08, 2009, 06:26:38 pm »
Can you check which version you are running. The latest is v14.0.0.7. The state is reliably being recorded on my Windows test instance. Let me know what platform you're on and I can double-check that one as well (I'm guessing Windows from "program files" but it pays to ask). I tested this with the -sc flag and it still works fine:
      "C:\Program Files\SlickEdit 2009\win\vs.exe" -sc config +new

Also, please let me know specifically how you are closing the window(s) and how you are opening them. Maybe one of the mechanisms isn't properly saving/reading that state. If the video is the easiest way to communicate that, then that would be great. I would never ask you to submit one to prove that you are actually having a problem. Sometimes, though, it is the best way to establish how to reproduce a problem.

On the problem with backups: what backup option do you have set? Can you post a screenshot of the Options > File Options > Backup screen? Maybe your options are specifying the location using the "Backup directory path" setting. SlickEdit defaults to using Backup History, and the default location for that is in the vsdelta directory, in the versioned subdirectory under your specified config directory.

With both of these issues, it would be useful to try SlickEdit with a completely default config. The best way to create one is using the -sc option and specify a location that never had a config in it before--that way it won't try to copy the settings from the previous version.

I've never questioned your frustration. One bug is one bug too many. We just want to work through them with you and make sure things are working properly.

jbhurst

  • Senior Community Member
  • Posts: 405
  • Hero Points: 33
Re: Where did Maximizing Windows Option go?
« Reply #7 on: April 08, 2009, 06:59:55 pm »
I didn't hit this problem, because I have _default_option('F', '1'); in my setup macro file, as Graeme suggested.

Here's how you do that:

Create a file, say "mysetup.e". Put the following in it:
Code: [Select]
#pragma option(strict, on)
#include "slick.sh"

defmain() {
  _default_option('F', '1');
}

I have many other options also set in my setup file.

After installing SlickEdit, invoke this file by entering its (path qualified) name as a command on the command-line.

Do not load it with the load command! defmain() files are batch macros, and are run as commands.

Regards

John Hurst
Wellington, New Zealand

Graeme

  • Senior Community Member
  • Posts: 2432
  • Hero Points: 322
Re: Where did Maximizing Windows Option go?
« Reply #8 on: April 08, 2009, 11:45:28 pm »

Scott that's the problem, it does not memorize the window state for me. That's why I was looking for that option in the first place. I could take a video and demonstrate it. Maybe there is a bug in SE when it is used with -sc command? I lunch it like this

%__utils_path%\..\se\win\vs.exe -sc %__utils_path%\..\se\config %2 %3 %4 %5 %6 %7

BTW thre is another bug with backups. Eventhough I tell SE to use %__utils_path%\..\se\config slick edit is still trying to (be default) backup my user files to c:\program files\slickedit\backup. This directory doesn't exist on my computer. So every time I close it it crashes. And this is another bug in a long stream of bugs in this release. Now I hope you understand my frustration. It is not because of one single bug (symbol coloring) it's bugs all over the place that affected me greatly.

If slick crashes every time you close it, it might not be saving your configuration so your maximize state doesn't get saved.  It should be easy to solve the backup crash issue if you have the time, so as Scott suggested, try and post some info about your backup settings.  The maximized window state gets saved when you close all windows or close the editor, so you could try doing "close workspace", then call save_config on the slick command line - or use the batch macro that John suggested.

Depending on your settings, you can change the backup directory location manually by editing vslick.ini (in your config folder) and setting VSLICKBACKUP=c:/somepath

Has using the %_utils% thing worked for you before as the backup path - maybe slick doesn't like it.  How did you assign it as the backup path - I can't see any way of doing that using the options dialog (that's why I manually edit vslick.ini myself).

Graeme