|
In lugnet.cad.dev, Anders Isaksson wrote:
> Steve Bliss skrev i meddelandet ...
>
> > Cool. Uhh, what about color? Augh! I don't want to think about that right
> > now.
>
> We'll think about it later...
I like that idea.
>
> > How about if LDList accepted the dragged parts as well as supplied them? When a
> > part is dragged onto the LDList list-window, that part would be added to the
> > set. Run two LDList sessions at once, drag parts from one LDList (the "parts
> > library" window) to the other (the "set builder" window).
>
> Sounds like a good idea - I'll test it when Real Life permits. Will LDAO also
> allow drag *from* LDAO to xxx? By using the same protocol you could use LDAO
> <--> LDAO drag'n drop, so you could take an 'official' model and drag the
> pieces into another LDAO where you're building an alternate model (we really
> have to fix color too!)
Yep. The idea is for LDAO to be both a source and sink for dragged parts.
> > Hmm. What about color?
>
> Yeah, what about color? We would have to increase the 'CopyRecord' structure
> with at least one more field, and I would have to include it in LDList in some
> clever way and...
Two approaches:
1. Allow multiple formats for the string being passed in the WM_COPYDATA
message. One format is the one you're already using, the part filename and
description. Another message could be defined that included color information.
A useful format for this second buffer would be a valid LDraw command.
Something like:
1 <color> 0 0 0 1 0 0 0 1 0 0 0 1 <partfile>
And (wandering off into left field) this message data format could be defined as
a snippet of LDraw code, instead of a single command. This would support
inter-program passing of almost any LDraw-related information. Multiple parts,
scaled primitives, submodels, whatever.
> I think building with restricted, correctly colored part packs is best solved
> LDAO <--> LDAO; Load a predefined part pack (.dat file) or use LDList to fill
> up with the pieces, set the color you need, and then drag the pieces to
> another LDAO (we still have to increase the CopyRecord struct). But please,
> convince me, and I might think about it in LDList too...
With a multi-format message definition, LDList could send messages just as it
does now. The view-window could be enhanced to handle the expanded format, or
not.
> > Not really, but it seems like you'd be pretty safe going with tab-delimited,
> > including field names for the first line.
> >
> > Example:
> >
> > PartID PartName Colour Quantity
> > 3001 Brick 2 x 4 Red 5
>
> Seems dangerous to me (sooner or later someone puts a tab in the description
> field, and everything breaks), I would like the <count>, <color> and <part
> number> as the first three fields (not necessarily in that order), the rest
> could be anything as far as I'm concerned.
I agree that it is best to move description to the end of the line. The only
problem is that not all parts have numbers.
The key thing is to have the headers on the first line, so the columns can be in
any order, left-to-right. It's not *too* challenging to write the file-reader
to handle this type of input.
Steve
|
|
Message has 1 Reply: | | Re: Suggestion for MLCad Plug-Ins
|
| Steve Bliss skrev i meddelandet ... (...) (where's the second approach?) (...) information. (...) Of course! Why didn't *I* think of that? (message type 2) (...) as (...) parts, (...) One long string with line separators? Or a multi-message approach (...) (25 years ago, 2-Feb-00, to lugnet.cad.mlcad, lugnet.cad.dev)
|
Message is in Reply To:
| | Re: Suggestion for MLCad Plug-Ins
|
| Steve Bliss skrev i meddelandet ... (...) We'll think about it later... (...) When a (...) Sounds like a good idea - I'll test it when Real Life permits. Will LDAO also allow drag *from* LDAO to xxx? By using the same protocol you could use LDAO (...) (25 years ago, 31-Jan-00, to lugnet.cad.mlcad, lugnet.cad.dev)
|
18 Messages in This Thread:
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|