Reloading is working now, but there are a few resource leaks.
No text editor yet.
Tried to commit, but got lost in your renames.
Here it is:
http://orbides.1gb.ru/orbf/genericvessel-reload-130519.zip
Thanks! I'll try to merge it in. On what version did you base your changes?
Two problems - how to detect that the focused vessel is our class (dialog is global)?
One way could be to check the class configuration to contain a "[CONFIG]" section with a "MESHNAME" key. Of course that is not 100% perfect, but it should suffice for starters.
EDIT: or better yet - if we already have the class configuration file, anyway - reading the Module parameter to see if it is "genericvessel".
And, resource deallocation is far from perfect - there are leaks, some of them with unknown plugability (meshes, drag elements and UMMU).
That was to be expected and one of the reasons I suggested focusing on a stable reload first. All the problems encountered here would haunt you in every incarnation of an editor, anyway. Just now the side-effects can be minimized.
This is the kind of situation for which i insisted on keeping the separate layers for Orbiter vessel and data structure creation - with it, you can swap xves to a link to the editor, and have the same exact module perform there, while with your SC3Data puncture it all becomes impossible.
SC3Data per se is no puncture of it, just encapsulation. You just have to use a different function call in the Init function of it or load another xves.dll. What makes it break are the subsequent UMMU and Payload classes with their Init functions, because they assume an INI file as underlying data model.
In this case, though, I'd refrain from skipping the INI file data model for an internal memory model, like you seem to suggest with the xves exchange. The reason I say so is simple: crash resilience. If we always use the PrivateProfile API of Windows, we can make small, immediate changes to the resulting INI file while not having to worry about keeping the data persistent. If we use "just" another backend that deals with memory directly, we will have to make that rock-solid.
For the first run without embedded editor, it is irrelevant, anyway. There we'd have to reload the file with every press of the button. How we update/re-create the current vessel representation (and how we get it solid) is independent from the load method.
---------- Post added at 18:50 ---------- Previous post was at 14:16 ----------
OK, I've pushed your changes as a commit deriving from your
master branch and named it
Artlav\reload. Looks good :thumbup:. I've also started to merge it into my branch, and besides the missing reload feature in my classes (obviously), it works, too.