Forum Replies Created
April 26, 2005 at 8:38 am in reply to: Access violations when opening files from the command line. #5482
We use the CreateProcess borland function with the comand line above.
It only ever executes 1 command line at a time – making only 2 instances of Mew32.exe – the original one and the one instantiated using the CreateProcess command.
How could we tell the existing instance of multi edit to open a file at a particular line number withould using the command line arguments to mew32.exe?
Surely running this command line will always start a second mew32.exe process at least until the second one realised that there was already one running and then passed the information to load a file over to it?
Therefore isn’t this issue more to do with the dual processor machines allowing the second mew32.exe instance to somehow get past this check in the code that there is another instance in existance.
We have used the workaround of the processor affinity for a couple of days now and have had no issues.
If you want me to check any updates to Multi Edit for this problem before release just let me know.
GraemeApril 25, 2005 at 9:12 am in reply to: Access violations when opening files from the command line. #5475
I have tried all of your suggestions to do with the -SR flag.
The -SR flag does not make any difference to the behaviour of Multi Edit in this instance.
After doing the Affinity ‘fix’ we have not had multi edit crash once!
There were definitly only 2 instances of Multi Edit running (Mew32.exe processes).
It does appear to be a timing issue in, perhaps in the code that tries to see if there already exists a copy of multi edit running?
Do you use a mutex to see if you have a running instance? (CreateMutex – borland version of this function)
This works well on our app to avoid multiple instances – we use Borland C++ builder 6.
GraemeApril 22, 2005 at 9:09 am in reply to: Access violations when opening files from the command line. #5471
You were correct, there were 2 processes of mew32.exe being created and the 2nd one was crashing.
It appears to have been solved by forcing the both the application that runs the command line and mew32.exe to run on the same CPU.
It was done using set affinity in the windows task manager – which is a little clumsy as it has to be done every time you start the process!.
I am now looking into how to do this automatically.
So far I have found imagecfg.exe that is part of the windows 2000 resource kit supplement one.
Also there is a Win32 api function to do the same thing that I might look into writing a small program to launch another with the affinity set.
Any other ideas (or do you know of such a program)?
Whenever I get this message I just click the Arrow (see picture) in the search box and then select ‘Clear All’ and this will fix it without hunting for files.
search.jpgMarch 22, 2005 at 8:04 am in reply to: Changing the date format the <CDATE> template metacomm #5373
That is great.
I did a search on the help and jut found the raw list of tags and a very short description.
Was this in the standard ME9.0.3 distribution?
I tried looking in ProcessExplorer and did not see any handles being created. I will try FileMon and the listing of all windows including hidden ones next time it happens.
We have a 15 user network version of multi edit 9.03 running on a windows 2000 server and a mixture of 2000 and xp clients.
I and 2 others are getting this error intermittently when trying to save files.
It gives the error when clicking the save button on the toolbar but will successfully save when you switch tasks.
We do not have the preview pane turned on.
We are using the project manager.
The files are on a local drive with no other applications accessing them (checked in process explorer and nothing – including multiedit – has a handle to the file)
Finally – before starting to write this post it was giving me this error and in the time it has taken me to write it it has stopped producing the error!
Hope that this helps,
Sorry – I am using Multi Edit 9.1 (although the behaviour was the same in 7.11)
The network connection is still valid – it happens if the connection is lost and restored – i.e. the server rebooted – disable and then reenable the network interface on your local macine and it still gives the same error.
Yes, I am using 9.10.3.
I tried this method with the original file, but without renaming it to c_gt.mac, and it works perfectly.
I tried adding the LoadMac c_gt to the startup.cfg and it did not make any difference.
I then tried changing the function name to CGTIndent and removing all of the other functions from the file that I hadn’t changed and this worked.
Editing the main c.s file would be the most elagant solution – although what would happen when the next update came along and overwrote the c.s file?
Would it be possible to add a global to the official distribution in the way that you mentioned to do this style of comment blocks? Defaulting to the original method.
I have had this happen before – unfortunatley I have not been able to recreate it reliably.
I have got administrator access.
I run the networked version of multiedit. I have noticed that if the connection to the server is lost at any point then the macro system stops working properly – every time a macro is attempted to be executed you get a dialog saying ‘error loading transient macro’. This also means that you cannot quit multiedit or load files. You have to kill Mew32 through task manager and then restart it.
Thanks for the suggestions.
I have experienced the problem of the process running after an apparant exit. It will stop multi-edit from loading again (at least on the machine with the process running) until you kill it.
Most (if not all) of the machines running multi-edit are windows 2000 SP4. Our usual policy is to shutdown machines overnight – thus killing the process – although might this killing of a process not free up a licence on the server?
If we get this problem again I will post any further information here.
I have read that section and we followed the procedure exactly, a very similar version of it came in the box as a printout. We had a working installation for a couple of months before the problem.
In point 3 on Page 17 of the PDF manual it says – “It does not matter how many clients are installed; what matters is how many are active at any one
time. Should a user try to run Multi-Edit at a time when all licensed seats are already active, Multi-
Edit will display an error message. Once one of the other users shuts his client down, the seat
becomes available, and the previously locked out user can then log on.”
Our problem was that it was reporting that all of the licences were in use but we had no copies of multiedit running on the network and after following the steps in my first post it all started working again, although it was not obvious what fixed it.
My request would be for a way of resetting what multiedit thinks the current number of users are if this was to happen again.
We had been using the licence sucessfully for a few months.
We have managed to get it working again – unfortunatley we cannot say for sure what solved the problem. We tried rebooting the server and this made no difference, then we tried renaming the reinstallation folder of multiedit from ME91x to ME91xORIG and then restored the original multiedit folder from the time that it had stopped working – and it suddenly started working!
If you have any ideas as to how the system of allocating how many users are currently logged on and using multiedit works would be apreciated in order to try and be able to solve this again in a more reliable manner.
It is also possible to turn this option off in the evolve configuration by unchecking the option to expand double quotes.