Question about auto restore of files

[ghamilto61]

Just made a jump from version 8 to 11.  In version 8 if you selected "Files" under "Auto Restore" options it would only restore the files if you didn't specify new files to edit on the command line.  In version 11 it restores everthing I've open, regardless of whether I specify new files on the command line.  Anyone know how I can get the old functionality back?
Thanks,
Gregg

[Graeme]

Just made a jump from version 8 to 11.  In version 8 if you selected "Files" under "Auto Restore" options it would only restore the files if you didn't specify new files to edit on the command line.  In version 11 it restores everthing I've open, regardless of whether I specify new files on the command line.  Anyone know how I can get the old functionality back?
Thanks,
Gregg

A couple of "sort of" ways - there might be a better way.  One possibility is to have a different configuration directory for when you want to specify the files to open  - add the -sc switch to the command line and specify a configuration directory.  Means duplicating all your settings in a second config directory.  Search for "invocation" in the help index.  See also the -sr option for restore path - dunno if that's useful for you.

Another possibility is to run a macro when slick closes down that saves the name of the current workspace or the names of all the files and then closes them, then when you run slick next time, run a dialog that asks whether to re-open the files or workspace.

Graeme

[hs2]

That seems somehow related to my request for a 'simple edit mode' to use Slick even for some quick-edit work _NOT_ restoring (and maybe corrupting) my complete workspace. But for my 'normal' project work I want to continue where I left...
What about an add. commandline switch telling Slick to ignore it's curr. save/exit flags and just to edit the files specified as arguments ?
HS2

[ghamilto61]

Thanks for the ideas!
I had another idea which was to modify restore.e.  I've made slight modifications to macros in the past to get the behavior I wanted, but it's been a while, and restore.e is pretty complex.  I haven't been able to locate where it makes the decision on whether or not to restore files.  I also need a way to determine if files were specified on the command line so I can tell it not to restore files in that case.
Can anyone point me in the right direction on this?

Thanks,
Gregg

[Graeme]

Thanks for the ideas!
I had another idea which was to modify restore.e.  I've made slight modifications to macros in the past to get the behavior I wanted, but it's been a while, and restore.e is pretty complex.  I haven't been able to locate where it makes the decision on whether or not to restore files.  I also need a way to determine if files were specified on the command line so I can tell it not to restore files in that case.
Can anyone point me in the right direction on this?

Thanks,
Gregg

If you diff vusrdefs.e before and after changing the auto restore options (need to close slick to get vusrdefs.e updated or do save_config on cmd line) you can see that def_auto_restore is set to one if "restore files" is enabled, otherwise zero.  The other auto restore options affect the def_restore_flags variable.  Searching for def_auto_restore you can see it in defmain in main.e  -   this seems likely to be the place but I'm not certain.  You might get some clues about cmdline options there too.  If you get desperate, you can invoke slick from a batch file that modifies an external file with some options that you can read when slick starts up.  The command line option to "run a command" appears to be for running an external program - I'm not certain of this or why you'd want to, rather than for running a slick macro.

Graeme

[hs2]

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.

HS2

[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.

--Scott

[Graeme]

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...

Graeme

[hs2]

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.

[Graeme]

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: [Select]

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

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: [Select]

_command void close_workspace_and_load_files() name_info(',')
{
   //messageNwait('### ' :+ arg() :+ '  '  :+ arg(1));
   if (arg() == 0)
      return;
   
   workspace_close();
   // optionally call workspace_open()
   edit(arg(1));
}
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.

Graeme

[jbezem]

...

• 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.

...

Yes, I would. For some larger projects I have two different workspaces, both with two projects. The smallest contains my current module(s) in one project, to be able to limit search-and-replace to just my module. The rest of my team's work is in another project for tagging purposes. The complete system is out of sight.
The other workspace contains one project with my team's work, including my newest module(s), and the full system in a second project.
Regularly, I switch between the two workspaces, but not between two sets of assignments. I'd be very happy if my workspace files (or any open file for that matter) would remain open when switching, since I only need to switch workspaces to enlarge or reduce the scope of global operations (a regular expression search in the complete system takes several minutes at best, in my team's software a few seconds...).

I've tried several combinations of options already, but couldn't find a satisfactory solution. And since you asked for feedback...

Regards,

Johan

[hs2]

Was a nice little challenge - especially to find out the proper Slick-callbacks
Try this, should work and hope it helps a bit.
(It's more or less derived from list_buffers().)

HS2

Code: [Select]

static typeless prj_buflist[];

void _sr_jbezem()
{
   // just as an example ('Cancel' button allows ESC to bail out)
   int result=_message_box(nls("\nDo you want to restore curr. open files later on ?\n\n"), nls("Closing workspace '%s' ?" ,strip_filename (_workspace_filename, 'PD')),MB_YESNOCANCEL|MB_ICONQUESTION);
   if (result == IDYES) save_buflist();
   else prj_buflist._makeempty();
}
void _prjopen_jbezem ()
{
   restore_buflist();
}

void save_buflist()
{
   int width = 0;
   _str result = '';

   int temp_view_id=0;
   int orig_view_id=_create_temp_view(temp_view_id);

   _build_buf_list(width,p_buf_id,false,p_buf_id);

   prj_buflist._makeempty();
   top();
   for (;;)
   {
      get_line (result);
      prj_buflist [ prj_buflist._length() ] = result;

      if (down()) break;
   }
   _delete_temp_view(temp_view_id);
   activate_window(orig_view_id);
}

void restore_buflist()
{
   _macro('m',_macro('s'));
   typeless status=0;
   p_window_id=_mdi.p_child;
   typeless buf_id=0;
   _str result = '';
   int i;
   for ( i = prj_buflist._length() -1; i >= 0; i-- )
   {
      result = _buflist_name( prj_buflist [ i ] );

      if ( _isno_name(result) )
      {
         parse result with '<' buf_id'>';
         _macro('m',_macro('s'));
         _macro_call('edit','+li 'buf_id);
         status=edit('+li 'buf_id);
      }
      else
      {
         _macro('m',_macro('s'));
         _macro_call('edit','+l 'result);
         status=edit('+l 'result);
      }
      if ( ! status )
      {
         p_buf_flags=p_buf_flags & (~VSBUFFLAG_HIDDEN);
         if ( p_window_state=='I' ) p_window_state='N';
      }
   }
}