subfiles in MPD files
2012-11-10, 18:40 (This post was last modified: 2012-11-12, 19:17 by Michael Heidemann.)
2012-11-10, 18:40 (This post was last modified: 2012-11-12, 19:17 by Michael Heidemann.)
I am still unhappy with subfiles in MPD files and what to do.
Example:
I have a file "testpart.dat" like this:
0 Testfile
0 Name: testpart.dat
1 16 0 0 0 1 0 0 0 1 0 0 0 1 3001.dat
1 16 0 32 0 1 0 0 0 1 0 0 0 1 s\testparts.dat
"testparts.dat" like this:
0 Testfile subfile blue
0 Name: s\testparts.dat
1 1 0 0 0 1 0 0 0 1 0 0 0 1 3001.dat
If I put the testparts.dat in a subfolder relative to the folder where testpart.dat resists I see with MLCad and LDView both parts.
Now I open testpart.dat in MLCad.
After that I import testparts.dat.
I save that content in the new file testpart.mpd
I would expect that I can now give this testpart.mpd to another user and that he can see what I have build, but that is not the case.
If I open the file from another location on my system MLCad claims "File s\testparts.dat not found! Continue loading?"
After I answered yes only the main color brick has been displayed.
One more bad thing with MLCad - if you export the files ("Multipart" - "Export Models...") the reference "s\testparts.dat" is changed to "Unknown".
With this behaviour it is impossible with the current tools to show the complete model direct out of the MPD file nor to export all files in a good shape.
For this reason I have in MPDCenter implemented a full export of the files in the correct foldertree and then all is shown correctly.
BUT MPDCenter is not designed as a viewer tool (build in viewer is ldvlib.dll).
To have also good experience with LDView I suggest to also implement something that avoid these mistakes.
Or, if we want to do it completely different, we need to forbit subparts to be in the MPDfiles. This can be archieved by changing all references to those subparts and delete the leading "s\".
But then one problem still remains - '48\' primitives. We can not just cut the 48 away, because then we have a different part (16').
Any other thoughts on this?
Example:
I have a file "testpart.dat" like this:
0 Testfile
0 Name: testpart.dat
1 16 0 0 0 1 0 0 0 1 0 0 0 1 3001.dat
1 16 0 32 0 1 0 0 0 1 0 0 0 1 s\testparts.dat
"testparts.dat" like this:
0 Testfile subfile blue
0 Name: s\testparts.dat
1 1 0 0 0 1 0 0 0 1 0 0 0 1 3001.dat
If I put the testparts.dat in a subfolder relative to the folder where testpart.dat resists I see with MLCad and LDView both parts.
Now I open testpart.dat in MLCad.
After that I import testparts.dat.
I save that content in the new file testpart.mpd
I would expect that I can now give this testpart.mpd to another user and that he can see what I have build, but that is not the case.
If I open the file from another location on my system MLCad claims "File s\testparts.dat not found! Continue loading?"
After I answered yes only the main color brick has been displayed.
One more bad thing with MLCad - if you export the files ("Multipart" - "Export Models...") the reference "s\testparts.dat" is changed to "Unknown".
With this behaviour it is impossible with the current tools to show the complete model direct out of the MPD file nor to export all files in a good shape.
For this reason I have in MPDCenter implemented a full export of the files in the correct foldertree and then all is shown correctly.
BUT MPDCenter is not designed as a viewer tool (build in viewer is ldvlib.dll).
To have also good experience with LDView I suggest to also implement something that avoid these mistakes.
Or, if we want to do it completely different, we need to forbit subparts to be in the MPDfiles. This can be archieved by changing all references to those subparts and delete the leading "s\".
But then one problem still remains - '48\' primitives. We can not just cut the 48 away, because then we have a different part (16').
Any other thoughts on this?