User forums > General (but related to Code::Blocks)
Multiple Instances
grv575:
--- Quote from: thomas on September 09, 2005, 04:58:34 pm ---The gotcha is this:
...
So what happens is you see your file opened in Code::Blocks, you work on, and ten minutes later, you realize that you have been working on two copies, neither of which is consistent.
The same can happen if you add new files to a project or change the build settings.
--- End quote ---
What about file change detection a lot of editors do? This would, whenever the window is made active, check the timestamp on the active file real quickly (or maybe all open files) and then alert the user the file has changed on disk - would they like to reload it or not. Very handy, I use this all the time in ultraedit since then you can just have a file open, run some command that changes the file, and then ue will just reload it for you (easier than browsing for the file again). This should keep files which are multiply open in sync as well.
--- Quote ---Lets see what can happen:
1. application starts, no other instance is running
---> no temp file is created. app does rm KNOWN_FOLDER/* to clean up (just to be sure)
---> everybody is happy
--- End quote ---
Yes but that create/delete file stuff is not atomic (and if you try to make it so, then you need to use OS locking stuff anyway). Crazy states that you did not anticipate or code for can make for some really strange behavior when you do this sort of stuff. For example, say the user highlights two files in explorer that they wish to modify. Two CB processes start and this type of IPC mechanism will more than likely fall over.
mandrav:
--- Quote from: grv575 on September 09, 2005, 07:49:40 pm ---What about file change detection a lot of editors do? This would, whenever the window is made active, check the timestamp on the active file real quickly (or maybe all open files) and then alert the user the file has changed on disk - would they like to reload it or not. Very handy, I use this all the time in ultraedit since then you can just have a file open, run some command that changes the file, and then ue will just reload it for you (easier than browsing for the file again). This should keep files which are multiply open in sync as well.
--- End quote ---
Already supported.
thomas:
Yiannis,
unluckily no... Windows does not use the running instance of Code::Blocks.
I don't know if there is a way that Windows will actually do that. There are such things on other platforms - on MacOS, if I remember well from the old days, you set a flag in the executable's resource fork, and it just works, but no idea about Windows. Googling on terms like "single instance windows" only gets you variants of using a mutex and raising a window which has the same class as your class. That is not particularly useful, though (n.b.: Dev-CPP has the very same problem as Code::Blocks, but for example MS Word works just fine, so it must *somehow* be possible).
The current alert box "another instance is already running, aborting now" does prevent damage, but it disrupts your workflow, hence my thoughts about how to pass the commandline to another instance.
grv575,
indeed Code::Blocks does check file modification times. However, that does not necessarily help. If you have a modified copy in RAM and minimize the application, you can still open the same file in another instance and edit that. Especially if your thoughts leap a lot from one thing to another (like mine do, unluckily) and if you always have 20-30 files open in every program, this can go unnoticed quite easily. Eventually, you realize you have three files with two versions each in RAM, and you have to manually merge them with copy and paste, which is quite annoying and error-prone. Especially since you don't remember what you modified in which version of any of the three files...
To prevent that, you would have to kind of... exclusive lock the file or something, but that is even more evil than tempfiles. If your IDE crashes, you have to reboot Windows to edit your sources, ouch...
Or keep a "codeblocks open files log" or something, maybe. This is not as bad as exclusive locking.
EDIT:
--- Quote from: grv575 on September 09, 2005, 07:49:40 pm ---Yes but that create/delete file stuff is not atomic (and if you try to make it so, then you need to use OS locking stuff anyway). Crazy states that you did not anticipate or code for can make for some really strange behavior when you do this sort of stuff. For example, say the user highlights two files in explorer that they wish to modify. Two CB processes start and this type of IPC mechanism will more than likely fall over.
--- End quote ---
It should be possible to make it "atomic enough" without much pain.
All you have to do is three things:
* Get all files from the directory (using wxDir::GetAllFiles, for example). This gives you a snapshot of what is currently in your directory, what comes after that is not your business
* Sort out the ones that are "old" (remember we were sent a message, this takes a few microseconds only, so everything older than 1-2 seconds can safely be ignored), and act on the ones that remain
* Delete all files you know about (so, not all files in KNOWN_DIR at that time, but all files you found earlier)
So, if two instances are started, three things can happen:
* Instance 1 notifies the running app after creating its tempfile, and instance 2 creates its tempfile a few milliseconds later (and notifies). The application scans the directory twice, opening file 1 on run 1, and file 2 on run 2.
* Instance 2 writes its tempfile before Instance 1 sends out the notification. The running app will scan the directory, and find both files, take action and delete them. Later, instance 2 will send out a notification, but without effect.
* Instance 2 creates a tempfile, but is not finished writing when the running app receives the notification from instance 1. No problem! Since the file is still exclusively opened for writing by instance 2, it cannot be deleted by the running app. The running app will therefore know it must ignore that file. After receiving the notification from instance 2, the app scans the directory as usual, and finds the same file again, opening it, etc.For this to work, the order of actions must be different of course, but the above is for clarity :)
mandrav:
--- Quote from: thomas on September 11, 2005, 12:48:21 pm ---Yiannis,
unluckily no... Windows does not use the running instance of Code::Blocks.
I don't know if there is a way that Windows will actually do that. There are such things on other platforms - on MacOS, if I remember well from the old days, you set a flag in the executable's resource fork, and it just works, but no idea about Windows. Googling on terms like "single instance windows" only gets you variants of using a mutex and raising a window which has the same class as your class. That is not particularly useful, though (n.b.: Dev-CPP has the very same problem as Code::Blocks, but for example MS Word works just fine, so it must *somehow* be possible).
to work, the order of actions must be different of course, but the above is for clarity :)
--- End quote ---
I don't use "single instance" C::B because I have to debug it :P
This may have something to do with it. If you allow multiple instances, at least in windows, it does re-use existing C::B instances for source files and projects. Only workspaces require a new instance to be launched - and this is intentional.
Maybe it only has to do with the single instance thing. Can you confirm this, because I haven't booted windows for a couple of weeks :P
thomas:
Confirmed. The following image shows:
1) instance created by double-clicking on app.cpp
2) another instance created by double-clicking on app.cpp again
3) instance created by clicking on taskbar icon, opening my default workspace
4) instance created by clicking on taskbar icon again, also opening my default workspace
It is possible to edit app.cpp in either editor concurrently (as shown) and it is possible to change projects and workspaces in either instance.
The in my opinion correct behaviour would be to put the instance having app.cpp already open to the foreground instead of spawning more instances.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version