LDraw.org Discussion Forums
LDInspector - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: LDraw Programs (https://forums.ldraw.org/forum-7.html)
+--- Forum: LDraw Editors and Viewers (https://forums.ldraw.org/forum-11.html)
+--- Thread: LDInspector (/thread-23882.html)

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14


RE: LDInspector version 0.2 - Orion Pobursky - 2020-04-14

(2020-04-14, 8:18)Stefan Frenz Wrote: Thanks for all your feedback helping me on my way towards LDInspector 0.3...  Wink

Willy's a taskmaster but a good one. I remember when I was active developing LDDP, when ever I would drop a new version, he'd come back with 30 more things for me to do. Made that program so much better. If I could find a good way to port it over to free compilers, I'd start developing again.


RE: LDInspector version 0.2 - Stefan Frenz - 2020-04-15

(2020-04-14, 19:51)Orion Pobursky Wrote: Willy's a taskmaster but a good one. I remember when I was active developing LDDP, when ever I would drop a new version, he'd come back with 30 more things for me to do. Made that program so much better.
Yes, I am very happy with the feedback and I value the time spent for testing and reporting.  Smile  Smile  Smile

(2020-04-14, 19:51)Orion Pobursky Wrote: If I could find a good way to port it over to free compilers, I'd start developing again.
Thanks for hinting towards LDDP. I didn't use it so far, but by looking at the screenshots and description, I have a strong feeling that the planned source code editing in LDInspector either will be not considered useful or will encounter very similar questions.  Wink  LDDP is written in Delphi and C++, isn't it?


RE: LDInspector version 0.2 - Orion Pobursky - 2020-04-15

(2020-04-15, 1:23)Stefan Frenz Wrote: LDDP is written in Delphi and C++, isn't it?

Just Delphi. But I don't want to pay for that any more. I tried to port to Lazarus/FreePascal but I'm using Scintilla editor control and some other third party controls that made life difficult. Also, if I switched to Lazarus's syntax highlighter control, I'd have to write a syntax highlighter plugin which I'm not excited about. LDPE has pretty much supplanted LDDP functionality anyway.


LDInspector - BrickLink Web search broken - Stefan Frenz - 2020-04-25

Bricklink just changed something at the web page / json return string, so LDInspector's BrickLink search on Web pane does not return anything at the moment with all versions. I'm working on this...


RE: LDInspector - BrickLink Web search broken - Stefan Frenz - 2020-04-25

Big Grin  Ok, Bricklink didn't change anything, they were in maintenance mode. Big Grin  Unfortunately, LDInspector cached even the "maintenance" message. Starting with the next version (not uploaded yet), LDInspector will dismiss cached web resources on structural errors.


current version update - Stefan Frenz - 2020-04-26

The current version checks for unsaved data before exit/refresh/load. Smile  For the next version still missing is the parser re-write to read FILE/File/file correctly and to detect additional comments (meta lines) in the first three lines correctly like in OMR 4565.


Header Meta question - Stefan Frenz - 2020-04-30

I'm very sorry for asking again. After reading several documents (like File Format, Official META Commands and Library Header Specification, thank you Mike for explicitly pointing to the Specifications Main Page) over and over again, and also after reading the corresponding part of MPDCenter-Source (where I found "IsValidHeaderMetaCommand" which allows at most "Name:, Author:, !KEYWORDS, !CATEGORY, !LICENSE, !LDRAW_ORG, !HISTORY, CMDLINE, BFC, !HELP"; thank again to Mike for providing), I still think that

(2020-04-13, 7:53)Stefan Frenz Wrote:
Code:
0 FILE 4565 - main.ldr
0 !LEOCAD MODEL BACKGROUND GRADIENT 0 0 0.74902 1 1 1
0 main
0 Name: 4565 - main.ldr
0 Author: Robert Paciorek [bercik]
0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt
could be invalid at the "0 !LEOCAD" Meta line in the header, especially because it is before the description "0 main".

So there are some options how LDInspector handles something like "0 !LEOCAD":
  1. Treat them generally as valid / ignore them, regardless of their position. Then I don't understand the docs, but it would be the easiest option to implement. Sad
  2. Treat them as invalid, but keep their position even if file is saved lateron. This would make LDInspector handling such lines equal to unresolvable references or mirrored parts (line is wrong, but you are the boss). This seems the neatest option to me, although it is the complicated one. Smile
  3. Treat them as invalid if position is before Author and always write them back after the header if file is saved. Diff to opt2: do not try to keep those meta lines before any Author field (line is wrong, and it is fixed always). Maybe this is what is wanted? Huh
  4. Not a real option: treat description and header as being "too" invalid. This is the current behavior of LDInspector I would like to change and I'm sure nobody wants to have, especially because there are some more "official OMR" files containing "0 !LEOCAD" before the description meta. Cool
Did I miss something? Do you have an advice for me or a wish how LDInspector should behave?

Thanks in advance and best regards
Stefan


RE: LDInspector version 0.2 - Stefan Frenz - 2020-05-01

(2020-04-08, 11:52)Willy Tschager Wrote: * Complains about filename s\364 - u572p02s01.dat does not start with parent OMR prefix "364 - "
Hi Willy, hi Roland,

thanks for insisting. I found the LDInspector branch and the comment I made: I adopted the LDCad behavior by integrating the prefix into the path. For example my small harbor sentry file was cleaned up by LDCad and afterwards contains "6245 - s\2551s01.dat" and not "s\6245 - 2551s01.dat".

I think the latter is what is wanted, but even if I change the filename to "s\6245 - 2551s01.dat" and then do LDCad cleanup again, it is changed to "6245 - s\6245 - 2551s01.dat". I am sure Roland has done the cleanup in this way by reason, but now I'm confused. Angel

Thanks for clarification and best regards
Stefan


RE: LDInspector version 0.2 - Roland Melkert - 2020-05-01

(2020-05-01, 15:54)Stefan Frenz Wrote: I think the latter is what is wanted, but even if I change the filename to "s\6245 - 2551s01.dat" and then do LDCad cleanup again, it is changed to "6245 - s\6245 - 2551s01.dat". I am sure Roland has done the cleanup in this way by reason, but now I'm confused. Angel

It should start with "s\*", this is a LDCad bug I totally forgot to fix in 1.6d Angry


RE: LDInspector version 0.2 - Stefan Frenz - 2020-05-01

(2020-05-01, 18:01)Roland Melkert Wrote: It should start with "s\*", this is a LDCad bug I totally forgot to fix in 1.6d Angry
Thank you very much for the fast response! And please don't feel angry Smile