LDStructure 1.0.0.0

[Michael Heidemann]

In another thread it was asked for a tool that shows the related parts and also the required parts for a library file.
I have so far a working result. The only thing I need now to implement is storing the results for the next use.
If someone is already interested in testing the current build, please drop me a note.



Just uploaded the latest build that should be error free. Thanks to all that help to make it error free.
Please download from my new webspace at ldraw.heidemann.org

To all that has already LDStructure installed: I have changed the place where the database is stored (under Win8 it is "C:\ProgramData", a hidden folder!)

Have Fun!

[Philippe Hurbain]

Sure I'm interested! Will it share LDFind database?

[Michael Heidemann]

No, that does not make sense to me.
In LDFind you can add directories to search also for parts. Those parts are stored in the same global database as the core library files.
LDStructure is designed to analyse the core library files and their dependencies.
So at present they will not share the database. But currently there is no database at all that i write to disc

The more different input you will have for applications the more difficult it becomes, as the current application can not know what any other application has done to the data in the database.

Therefore I have to think deeply on this issue.

[Roland Melkert]

Just curious, but why not?

All you need to add to the LDFind xml are the type 1 lines per part and and the file type so you can filter out primitives etc when using normal searching. LDStructure could then recursively go trough all data without having to load any .dat

You could even consider expanding LDFind to do all these things in a single app, making it a very powerful search tool.

[Michael Heidemann]

Yes, that is a good question. I also have thought in that direction too but could not see a real benefit. I try to explain:

LDFind:
Uses a database where the header data from dat files are stored. (official and unofficial/custom).
Based on that database a second search database is build depending on the settings the user makes.

LDStructure:
Uses at present no database
The internal structure is of course similar, but i need to ensure to have all files in place therefore I have limited it to the official files (_all_) as the basis of analytics.
All these files are scanned for required parts. The result is stored separately in required files and related parts.

If we use the same database as LDFind we can not be sure to have _all_ files in the main database and that would cause for sure errors in LDStructure. At least the base for all work is the official libary that is stored on the users system, but in LDFind you can work with only a subset of that files (parts.xml) or on a wider range of files (adding custom folders). Therefore you will need to look for the right files every time you start LDFind or LDStructure.

I my eyes this does not make sense at all. During writing these lines my opinion to not share the stored database has strongen!

[Magnus Forsberg]

Hi Mike

Why is LDStrucure only searching the official library?

To me, my "library" is very dynamic. I try to download all new files from the PartTracker as soon as possible.
If an official file is updated by a new version at the PT, I remove the "old" files from the "official" folders. I move it to an "old files"-folder.
I do that because I only want to have an always updated library. Maybe this practice is unneccesary, but I don't like the idea of having duplicate files, one official and one unofficial, on my system. I know, after having tryed it, that MLCad and LDView only show me files from the "official" parts-folder, if I have duplicated files, one official and one unofficial.

How do the part selection take place in programs like MLCad, LDView, LDCad, Sr3dBuilder, and others?
How do they know wich folder to pick a part from? I only want to see/build with the latest versions of the parts.

[Michael Heidemann]

I understand your thoughts, but you might run into much trouble with what you are doing.
If you using unofficial files in your models they might get broken once the file becomes official and is rotated or shifted or renamed!

The file selection should be done in the following order (IMHO)
Official files
other sources

But you can change (if I remember correctly) the search order in MLCad and LDView.

Code:

Why is LDStrucure only searching the official library?

Well, because that is what should be similar on _all_ machines, so I am able to see the models you have done in the same shape like you on your system.
I know that many people do it in a different way, but this results very often in not readable models (file not found!).
So my focus is clearly on the official files.
But this means in most cases the files that are on you system in the folder
%LDRAWDIR%\parts
%LDRAWDIR%\parts\s
%LDRAWDIR%\p
%LDRAWDIR%\p\48
So if you run LDStructure the first time on your system all files are scanned in those folders! Not only the official files!

Currently there is no detection of changes made in those directories, so the next time you change a part the changes are not reflected in the results of LDStructure. Or if you add a file to those directories, this file will not be scanned at all (currently)!

Until an update mechanism is present in LDStructure you need to delete the database file LDStructure.xml to force LDStructure to rebuild that file.

[Michael Heidemann]

Just updated LDStructure to use commandline.
"LDStructure 1.dat" will load LDStructure and show 1.dat if found in the list.

Please download from website

[Philippe Hurbain]

Uh oh... I see an integration with LDFind coming

[Michael Heidemann]

Yes
But not that good like i wanted to do it. My skills are not good enough to let both applications talk to each other

[Philippe Hurbain]

Maybe it's not elegant, but it does the trick!

[Michael Heidemann]

Yes, thats the reason why I released now this version.

I would very much find a way to not start for every file a new instance of LDStructure.
I have reached this already by using the clipboard. But the result was too slow for the application afterwards.
I could realize this also by using a file where I check for changes. But also this is not what I am thinking about.
I should be able to find another solution, so that I can control LDStructure from LDFind.
If there is somebody that knows how to solve this, please contact me.

[Roland Melkert]

You need to use a mutex for that, examples should be findable quite easily.

[Michael Heidemann]

I have found this: (german) http://msdn.microsoft.com/de-de/library/...90%29.aspx

If I understand you correctly I need to implement in both applications the source like mentioned and in one "UseResource()" I set a value and in the client applications "UseResource()" I get the value.

Is it that easy?

[Roland Melkert]

My german isn't that good

What you want is block the extra instance(s) of LDStructure ?

In the program create a mutex as soon as possible using a semi unique name. When the creation of this mutex (handle) fails it means the mutex is already in use (created by another instance). So instead of continue starting the current LDStructure you send a message (broadcast really) to the existing one and terminate the (second) instance. The other (first started) instance will get the message (containing the command line params of the terminated instance) which you can use to add a tab / window or whatever.

This is basically it. You'll probably also need to look into handling cross application messages, kinda forgot about that

[Travis Cobbs]

If you're interested in having them talk to each other, contact me, and hopefully I can give you some pointers. Note: saying your skills aren't up to the task doesn't (to me) imply that you're interested, so I'm not trying to push you to do so. However, LDView on Windows has an experimental "remote control" interface (that's not advertised, and only allows you to highlight parts, nothing else), so this is something I've done in the past on Windows. Granted, LDView uses C++, but many of the concepts should be the same in C#, since the inter-process communication uses standard Windows functionality.