SlickEdit Product Discussion > SlickEditĀ®

Question about auto restore of files

<< < (2/3) > >>

I already patched main.e / restore.e / window.e to achieve the following behaviour:
(my Slick config says that 'normally' I want to restore almost everthing and I invoke Slick with '+new' option)
a) if some <files> are specified as commandline args just the window layout etc. restored but no workspace is loaded
b) if a 'workspace/project' file is specified, I get asked whether to load it or just to do some editing (or bail out) -> on edit see a)
Sometimes I prefer to edit my workspaces/projects directly.
c) when exiting I just skip everything related to saving configuration when no workspace is active

It's not the smartest solution, but works for me. The problem is that hacking main.e is dangerous ...
I had some troubles in the past installing Slick updates.
Well, now I know ... ;)
Therefore I like to get 'official' support for (at least) the quick-edit feature.


ScottW, VP of Dev:
I was reading this thread, and I think we can improve the auto restore functionality as it relates to files.

Here are the behaviors I see if I select Tools > Options > General and put a check in the Files checkbox or Workspace File:

"Files" only:
1) Switching workspaces preserves the currently open files. So, if I open workspace A and open 2 files from that workspace, then switch to workspace B, the 2 files I just opened in A are still open.
2) Closing SlickEdit and reopening it brings up the last open workspace and all open files.

"Workspace Files" only:
1) Switching workspaces opens the files that were open the last time I used that workspace, closing any that I opened in the first workspace.
2) Closing SlickEdit and reopening it causes SlickEdit to open with no files open, even though they were open when I closed SlickEdit. If I now switch workspaces, the files that were last open in the other workspace are loaded.

"Files" and "Workspace Files":
1) Switching workspaces behaves as described in Workspace Files only.
2) Closing SlickEdit and reopening it behaves as described in Files only.

The current choice of names, "Files" and "Workspace Files" is confusing and doesn't give much in terms of predictability for what to expect.

I propose the following:

* Drop the "Workspace Files" item. Checking the "Files" item would behave as described above, in "Files and Workspace Files".
* Optionally, add a checkbox labelled, "Keep files open during editing session". When checked, all files open during that session will be open until closed, even if you switch workspaces. Would anyone ever use this? I wouldn't.
* Add a checkbox labelled, "Don't restore if file names are specified on command line", or something better that conveys the same meaning. When checked, if SlickEdit is launched with command line arguments specifying files to edit, then SlickEdit comes up with no open workspace and just those files open.
OK, I need your feedback to guide us. Let us know what you like and we'll see if we can get this in v12.



Currently I use "Files" and "Workspace files" because files only and workspace files only options aren't viable for me.  I doubt if I would use the option "keep files open" you mention because this would contaminate the newly opened workspace  - if at all, this would be better not as a permanent config option but as an option when you actually switch workspaces.  I would prefer a command line option to inhibit/force the opening of the last workspace in addition to the checkbox to prevent opening the workspace if files are specified on the command line.

It might also be useful to be able to specify a macro name and arguments on the command line with the macro being run when slick starts up, after all other initialization has been done.

Currently it's essential for me that when I switch workspaces, the files from the current workspace get closed and the files from the other workspace are opened because I am in the process of working out how to merge code from two different projects.  It's possible that maybe I should have both projects in the same workspace which I guess means that when I switch projects, no files get opened or closed.  I need to switch projects so that the tagging works.  Having both project file sets open at the same time would mean lots more files open at the same time I guess but maybe it would work better for me.

Looking forward to V12...


I fully agree with Graeme. This is exactly what I wanted to post, but he is just quicker ;)

For me there are basically 2 use-cases:
1. project/workspace related work, where I want to re-start my work in the same environment where I left ...
-> curr. Slick-behaviour is quite OK (except my request for workspace related (auto-)tagfile lists, but that's another thing)
2. doing misc. (quick-) editing stuff, where I don't want to pollute my project related stuff
I just want to edit 1 or more files and exit (while another instance with workspace loaded is running) w/o restoring all the stuff  I normally (see 1.) want to restore _and_ without saving any related configuration (which obviously fails, when another Slick is up).

For 2. I would prefer that nevertheless the window layout is always restored.
That's more or less what I hacked into my main.e/restore.e/window.e.
The distinction between 1. and 2. is made by checking commandline args for specified files to edit (with support of 'Edit or Load ?' workspace/project files).
I think it would be better to have an add. commandline switch for that.

rgds, HS2

PS: The possibilty to modify Slick itself ('Use the source, ...') is one of really big points along with compiler independent tagging support ... A must for 'non-standard' work (?) as embedded / driver development.


I implied in a previous post that running a slickedit macro that is specified on the command line that invokes slickedit wasn't possible  - but I was wrong.

The help file on invocation options confused me a little but as a result of discussing nameinfo issues in another thread I realised you can run any macro you like at startup so I've found the following works on Windows XP (SP2).

Create a batch file with something like the following  - the pause line is optional.
I don't know if %* in the batch file works in other versions of Windows.

--- Code: ---pause %*
start L:\Apps\vslick\win\vs.exe -sc L:\gp\vslick\config2 +new -#"close_workspace_and_load_files %*"

--- End code ---

Set the target in the Windows "SendTo" shortcut for slickedit to be the name of the above batch file e.g. c:\temp\some-batch-file.bat.

Create and load a slickC macro as follows

--- Code: ---_command void close_workspace_and_load_files() name_info(',')
   //messageNwait('### ' :+ arg() :+ '  '  :+ arg(1));
   if (arg() == 0)
   // optionally call workspace_open()
--- End code ---

After loading the above macro, close slickedit or do save-config on the command line.

Now you can select one or more files in Windows explorer, right click and send to the slickedit target.  The selected files get opened and any previously opened workspace gets closed without the new files being added to that workspace - (this behaviour could change in future releases of slickedit).

The +new in the batch file runs a new instance of slick  - if this isn't wanted then possibly a little bit more work is needed to just add the selected files to an existing slick instance, depending on the desired behaviour e.g. without closing the workspace.  Removing +new from the batch file has a strange effect  - the macro still gets run but the %* filenames aren't passed to the macro - instead slick treats them as files to be opened - hence because arg() returns zero, the workspace isn't closed and the files are opened.  The only way I can think of to get the slick macro above to detect that slick was already running is to use a timer that cleared a flag 5 or so seconds after slick starts running - if anyone wants to know how to do that, just ask...

I'm not entirely sure that the passing of arguments on the command line to a slick macro works exactly as it should  i.e. I probably ought to be able to do the above without a batch file but I had some problems and switched quickly to the batch file method and didn't try very hard to get it to work.



[0] Message Index

[#] Next page

[*] Previous page

Go to full version