Switching projects when changed files not saved yet

[samej71]

Hello,

I have ME 10.05 with session/project management turned on.

Sometimes I will be editing a file and I get interrupted and need to switch to a different project. If I forget to hit "save" on the edited files before changing projects, I will get an alert that I have files open that aren't saved. It prompts me to "save modified files?" with options for "yes", "no", and "cancel." Since I want to make sure I don't save a file that was left in an unstable state (since our files are "live" or immediately effective on our development tier), I hit "Cancel" so I can review the changes, finish up or comment-out any changes that are "in the middle" of being complete, and then saving the file(s).

However, ME is in now in an "inbetween" state. The file editor windows that are open all belong to the original session/project, but the project in the project view pane reflects the project I wanted to switch to before hitting cancel (can you say "Sybil"?). So it is as if the project pane wasn't aware that I hit cancel. I then have to "switch" back to the original project (which does not have any effect on the open files) and *then* switch back to the desired project. At that point, since there are no unsaved files, it will work correctly.

This issue has been around for a number of versions (possibly even as far back as 8 or 9) but I've never gotten around to reporting it before.

Thanks for listening!

--James

[Michal Vodicka]

I won't address MEW issue; if you're right, it should be fixed. Instead, I was a bit surprised with the way you work. If I understand correctly, you edit live files which are used by other developers in parallel. You can't save files in the intermediate state and have them only in memory. Autosave probably has to be turned off.

Well, I can't imagine to work this way. There are several dangers. You can lose all your changes because of software or hardware failure (BSOD, power outage etc.). Others' development can be influenced if somebody saves files by mistake. Data can be lost if several developers edit the same file. If more files are edited at once, parallel saving can lead to data loss and inconsistent state. Etc.

Above are reasons why to use VCS/SCM systems for this kind of development. Every developer edits his local copy of files checked out from depot, saves them locally when necessary and once the change is finished, submits whole set of files to depot at once. Other developers have their own copy and sync with depot when decide so (nobody else can change their local files). If there is a conflict (parallel changes), software warns about it and allows to merge changes. Currently, the best is probably Perforce which makes all changes transactional but it is also the most expensive. SourceSafe or free solutions would serve as well, especially for small teams. Everything is better than what you described, if I understood it correctly Maybe not because I can't imagine how to, for example, run compiler without saving files first.

[samej71]

Hello,

Overall, yes, its a rather odd way to work, but the group I'm in is not a traditional software development house All of the points you've mentioned are valid.

To provide a little background, since you seem to be interested:

We have a small team of 9 developers, each one working on an unrelated project. We do have a few core modules that are shared, but they are rarely updated. We don't run into issues of multiple people updating the same file at once due the nature of our work.

We use PERL and develop web applications that have database access. So, we don't have "compilation" issues like a traditional software house would have with C, VB, Delphi, etc. We primarily use Windows (some of use Linux) on our desktops with our editor of choice (mine is, of course, ME) to edit files located on Solaris server over a SMB mount.

Since we're writing web services that run on a Solaris box, we'd need to create rather complex sandboxes with separate database instances (so if someone were updating a core module that referenced a database table, it could have a different structure than the ones everyone else is using) for each developer. The setup and maintenance of all of these independent web servers and databases and synchronizing changes would introduce more delays and difficulties than the current system. We'd also need more DNS entries for each developer that works on each project, so each developer could access each project they have worked on or might need to work on in the future. There is significant overhead required to set up and maintain everything that would be needed for all of the developers to have private web servers, databases (both structures and data), perl modules, other libraries used (glibc, etc).

We do have version management in use, but we use it at a server-level instead of a per-user (sandbox) level.

Yes, I have autosave turned off. I typically have no more than 10 lines edited before saving and testing; so even if my desktop HD goes out, I'll lose far more time installing a new OS and ME than I will in work due to the handful of lost lines of code.

I know all of this must seem very foreign to you, it's okay. It's an odd setup but it works remarkably well for us. I can get a bug report or feature request and literally have it in place and live on our development platform for preliminary testing in less than 30 seconds. Rolling the change to our QA and production tiers takes longer, since it involves our source control system.

You may wonder if the code we write is separate from the projects the other developers are working on, why is saving a file in an intermediate state a problem? We have a different team of "GUI" developers that handle the front-end of the web services we write the back-end for. Any compilation errors in the back end would prevent them from using the web service to render their HTML templates, should they be working on the project the same time we are.

Again, this isn't to negate any of the points you've mentioned. They are all absolutely 100% valid. We're a horse of a different color and we don't have the issues you've mentioned. I've left out details just so I didn't write a novel, so I'm sure there are still things that might perplex you.

We do have some C/C++ developers in a different group that work on a traditional compiled application, and they use version control in the manner you've mentioned. And when I worked on a C++ desktop application years ago that's how we did it then too.

...and if you're curious, we use Perforce.

--James

[Michal Vodicka]

Thanks for detailed explanation. Yes, it still looks a bit strange for me but if it works well for you, it is OK.

[deleyd]

Actually the project hasn't been changed yet. The correct current session is listed at the top of the Session Manager dialog box. The session manager however highlights the wrong line in the list of sessions. Here's a fix for that bug:

1. Find SessMgr.s
It's usually in
C:\Program Files\Multi-Edit 2006\Src\

2. Edit SessMgr.s
Line 686 reads:

Code: Select all

Find_Text( "/x7F" + "NAME=" + old_sess_name + "\x7F", 0, 0 );


That first "/x7F" has the slash in the wrong direction. It should read

Code: Select all

  Find_Text( "\x7F" + "NAME=" + old_sess_name + "\x7F", 0, 0 );

Make that change.

3. Compile:

1. On the Multi-Edit menu across the top, select TOOLS -> EXECUTE COMPILER...
2. Select COMPILE CMACWIN MACRO (ADMIN), and click 'Select'
(Note: if you are running ME2006 10.04 OR 10.05 be sure to select the (Admin) version)
(For more help on compiling CMAC code see "Introduction to CMAC. 1: Hello World" at http://www.multieditsoftware.com/forums ... .php?t=359)

and then do this step:

1. Exit Multi-Edit
2. Go to START -> ALL PROGRAMS -> MULTI-EDIT 2006 -> REBUILD MACRO LIBRARY

[samej71]

Hello!

Thank you for your reply.

Actually the project hasn't been changed yet.

Correct, which is why the project displayed on the "project" pane is wrong (the name changes and shows the project you selected to change to, even though in all actually it's really still the original project -- the name shouldn't have changed).

I made the change you've outlined, recompiled all macros and then rebuilt the macro library (I've done this before to incorporate some changes in mew.s write work). Unfortunately, the bug persists. The "project" pane (view/tab) still shows the wrong project when I hit "cancel".

The correct current session is listed at the top of the Session Manager dialog box. The session manager however highlights the wrong line in the list of sessions. Here's a fix for that bug:

I don't use the session manager directly, I just use the "project pane" to manage my projects (and thus sessions). Perhaps there's a different section of code with a similar issue?

Thank you for looking into this.

--James

[deleyd]

I see where the problem is. I added it to my list of bugs to fix.