Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
Whenever I open my plug to edit, it says it is currently being used, but Mission Computer 1.3 is the only application running apart from Finder. Why is this happening?
------------------ Hand me the gun and say that again.
Okay, I just tried another plug, and that works so the origional file is just probably corrupted, but not as soon as I design a new dude, it quits because of an error of type 2. Why is this happening?
Great, not this plug isn't working because it is supposedly in use. WHAT IS HAPPENING? AAAAAARRRGGGG :mad: :mad:
Are you using MissionComputer 1.3, or MissionComputer 1.3.1? Classic or Carbon? Also, do your plug-ins open properly in ResEdit?
------------------ David Arthur (url="http://"http://davidarthur.evula.net/")davidarthur.evula.net(/url): MissionComputer and the Talon plug-in (url="http://"http://www.ev-nova.net/")EV-Nova.net(/url): Yes, the forums are back! (url="http://"http://www.evula.com/")EVula's Lair(/url) | (url="http://"http://www.evula.com/survival_guide/")EV Nova Survival Guide(/url)
I'm using 1.3.1 and when I open them in Res-edit, it says they are damaged beyond repair? Could Mission Computer have caused this?
Okay, I dumped all the damaged files and backed up my working file seven times, so if one does get corrupted I wont lose 1 months work, but when I change anything about them in Mission Computer 1.3.1, it quits because of an error of type 2. So what I'm basically asking is.
Thanks in advance.
Quote
Originally posted by Zax: **Okay, I dumped all the damaged files and backed up my working file seven times, so if one does get corrupted I wont lose 1 months work, but when I change anything about them in Mission Computer 1.3.1, it quits because of an error of type 2. So what I'm basically asking is.
**
I am assuming that, due to the error, you are running OS 9. An error of type 2 is an Out of Memory error. Basically, allocate more memory to MissionComputer because it can't load your plug into memory. Usually, in any program, the bigger the file you are working on, the more memory the program needs. If this isn't the case, then I have no clue : ) But, it definitely has something to do with running out of memory.
There is no such thing as a Type 2 error on OS X.
Jeffrey
------------------ (url="http://"http://www.ariossoftware.com/upcoming")EVONE 1.0.0 - the plugin editor for EV/EVO/EVN(/url)
Originally posted by AriosSw: **I am assuming that, due to the error, you are running OS 9. An error of type 2 is an Out of Memory error. Basically, allocate more memory to MissionComputer because it can't load your plug into memory. Usually, in any program, the bigger the file you are working on, the more memory the program needs. If this isn't the case, then I have no clue : ) But, it definitely has something to do with running out of memory.
I allocated it more memory, 50 megabytes actually, but it still quits.
Hey,
I seem to remember this error happening to me waaay back... I suggest you delete your preferences (The MissionComputer ones) and open a new, untouched copy of your plugin. It's been a while since that happened to me, but I'm pretty sure that's the solution, or at least a solution.
Hope that helps, Scifiteki
The error number has very little meaning in this context, as MissionComputer does not load the entire plug-in into memory. Because of the various safety mechanisms built into MissionComputer, the fact that the files are becoming damaged probably means the error is actually occurring during the write process. Is there anything out of the ordinary about the plug-in you're working on? Does this only happen when you create a new düde resource as you described? If so, does it happen after you save the resource, before the resource editor dialog appears, or inbetween?
Alright, I think I can answer a few questions. The reason ResEdit says the file is in use is becuase it is in use - the last application to open it did not close it. MissionComputer was the last application to open it and it did not close it because it crashed (the system does not close opened files when an app crashes). Thus, assuming MissionComputer does not keep the file open the entire time it is being edited, but only when it actually needs to write, we know that the program began to write the file. Since ResEdit claims it is damaged beyond repair, the crash either occurred between the calls to AddResource() and WriteResource(), or during WriteResource(). MissionComputer is checking ResError() between the calls, right?
Originally posted by AriosSw: Alright, I think I can answer a few questions. The reason ResEdit says the file is in use is becuase it is in use - the last application to open it did not close it. MissionComputer was the last application to open it and it did not close it because it crashed (the system does not close opened files when an app crashes). Thus, assuming MissionComputer does not keep the file open the entire time it is being edited, but only when it actually needs to write, we know that the program began to write the file. Since ResEdit claims it is damaged beyond repair, the crash either occurred between the calls to AddResource() and WriteResource(), or during WriteResource(). MissionComputer is checking ResError() between the calls, right?
MissionComputer is based on a higher-level resource framework, so that doesn't come into play - basic error checking and so on is handled automatically. MissionComputer only opens the file while it is reading or writing, and closes it immediately afterwards, so if the file was not closed, the crash must have happened during a read or a write. I'm waiting for Zax to tell me exactly where this crash is happening so I can tell which it is.
Oh, and Zax, are you working on a plug-in for Escape Velocity, or for EV Override?
Originally posted by David Arthur: **MissionComputer is based on a higher-level resource framework, so that doesn't come into play - basic error checking and so on is handled automatically. MissionComputer only opens the file while it is reading or writing, and closes it immediately afterwards, so if the file was not closed, the crash must have happened during a read or a write. I'm waiting for Zax to tell me exactly where this crash is happening so I can tell which it is.
Oh, true, I assumed C. : ) By the way, what framework/language are you using?
Anyway, from my experience, a program can only damage a resource file beyond repair when it is writing, reading should have (obviously) no effect on the file whatsoever. The fact that the file simply wasn't closed does not corrupt the file. Of course, it all depends on what the framework you are using is doing.
This is the only time that pure C is easier than a framework - you know precisely what your program is doing. Of course, there are also more opportunities to make a mistake. Eeek a bug.....
Jeffrey - Arios SoftWare
Originally posted by AriosSw: By the way, what framework/language are you using?
As a matter of fact, it's primarily housed in REALbasic, with a few third-party and custom application frameworks installed.