 | | Re: Ldglite must be faster
|
|
(...) I am. I actually started using it again recently. Generally, I find LDList faster than any other option. (...) Nope, I didn't know that. Thanks for mentioning it! :) (...) I wanted to, but I got bogged. I'm currently looking for the (...) (22 years ago, 3-Sep-02, to lugnet.cad)
|
| |
| | Re: Ldglite must be faster
|
|
"Steve Bliss" <partsref@yahoo.com> skrev i meddelandet news:s5q9nuc5pr24nbv...4ax.com... (...) then (...) Just fix a DLL and it can be embedded into an ActiveX for anyone who thinks he really needs it... (An ActiveX control is just a DLL with a (...) (22 years ago, 3-Sep-02, to lugnet.cad)
|
| |
| | Re: Ldglite must be faster
|
|
(...) An ActiveX control would be very useful for "all those little helper programs", where the programmer really doesn't want to worry about all the standard Windows grunge. Especially if the ActiveX control could add value over a disconnected (...) (22 years ago, 5-Sep-02, to lugnet.cad)
|
| |
| | Re: Ldglite must be faster
|
|
(...) Hmmm, an LDRAW Graphics Server, that could be nifty. But how about using XML-RPC to talk to it instead of WM_COPYDATA? Then you could control it from any platform, or a browser, or even a telnet session if you like typing raw XML. Don (22 years ago, 5-Sep-02, to lugnet.cad)
|
| |
| | Re: Ldglite must be faster
|
|
"Steve Bliss" <partsref@yahoo.com> skrev i meddelandet news:utvenuov1aga5rp...4ax.com... (...) Server), (...) WM_COPYDATA (...) It shouldn't use WM_COPYDATA, that was just a joke. No, I meant: Just another program which gets commands through Windows (...) (22 years ago, 5-Sep-02, to lugnet.cad)
|
| |
| | Re: Ldglite must be faster
|
|
"Don Heyse" <dheyse@hotmail.spam....away.com> skrev i meddelandet news:H1z7p3.8G7@lugnet.com... (...) Nah, the WM_COPYDATA was just a joke :-) I know that's not platform independent. What's XML-RPC? What's wrong with ordinary sockets? Or were you (...) (22 years ago, 5-Sep-02, to lugnet.cad)
|
| |
| | Re: Ldglite must be faster
|
|
(...) Ah. We've got that already - ldglite in offscreen mode. (...) That's the downside. (...) Right. That's what I thought device contexts basically were. Maybe I'm misremembering; sorry. (...) The final Z values of each pixel. I'm not sure how (...) (22 years ago, 5-Sep-02, to lugnet.cad)
|
| |
| | Re: Ldglite must be faster
|
|
(...) How responsive would XML-RPC be? Would it be an appropriate approach for an interactive program (as opposed to a program that needs a relatively static display)? Steve (22 years ago, 6-Sep-02, to lugnet.cad)
|
| |
| | Re: Ldglite must be faster
|
|
(...) Well it sits on top of HTTP, which builds up and then tears down a TCP connection for each message, so it's not the fastest protocol in the world. How many messages per second do you think you need for an interactive program? What are you (...) (22 years ago, 6-Sep-02, to lugnet.cad)
|
| |
| | Re: Ldglite must be faster
|
|
(...) Actually, while it doesn't support WM_COPYDATA, I did just add a function to ldglite (for Windows) to paste text from the clipboard into the LEDIT emulation mode on a CTRL-V. So now it can get part names indirectly from LDList via the (...) (22 years ago, 6-Sep-02, to lugnet.cad)
|
| |
| | Re: Ldglite must be faster
|
|
(...) Oops, forgot to paste the URL. Look here for more info. (URL) (22 years ago, 6-Sep-02, to lugnet.cad)
|
| |
| | Re: Ldglite must be faster
|
|
(...) Ah. (...) Hmm. Probably not raw keystrokes, but possibly sending messages at keyboard speed. I was basically thinking of anything an editing program might need done for rendering (and interaction) services. XML-RPC would be asynchronous (I (...) (22 years ago, 6-Sep-02, to lugnet.cad)
|
| |
| | dragNdrop (Was: Ldglite must be faster)
|
|
(...) Let me clarify this. I think I have drag-N-drop from Windows Explorer under control. That uses WM_DROPFILES messages and the protocol is described on the internet. I'll have to see what I can do when someone drags a whole list of part files (...) (22 years ago, 6-Sep-02, to lugnet.cad)
|
| |
| | Re: dragNdrop (Was: Ldglite must be faster)
|
|
"Don Heyse" <dheyse@hotmail.spam....away.com> skrev i meddelandet news:H218Ln.8Hn@lugnet.com... (...) If you read Pascal, take a look at the LDList source, it is both source and sink for the D&D of LDRAW parts that I (and Steve) defined. Otherwise I (...) (22 years ago, 7-Sep-02, to lugnet.cad)
|
| |
| | Re: dragNdrop (Was: Ldglite must be faster)
|
|
(...) It appears to be a mess of desktop system specific protocols (KDE and Gnome) in addition to the standard X11 "clip board" (see section L.2, "Peer-to-Peer Communications via Selections", pp. 370 in "X Protocol Reference Manual") which is The (...) (22 years ago, 7-Sep-02, to lugnet.cad)
|
| |
| | Re: dragNdrop (Was: Ldglite must be faster)
|
|
(...) I examined the source (aren't you glad you posted it) and now I can drag in a part from LDList (cool!), but I'm still not sure about the rest of the 'protocol'. What's the point of the X and Y coordinates? And is it the empty message that (...) (22 years ago, 9-Sep-02, to lugnet.cad, lugnet.cad.dev)
|
| |
| | Re: dragNdrop (Was: Ldglite must be faster)
|
|
(...) I guess I'll have to do some tests in KDE and GNOME to see it the X selection buffer still works. It'd be nice to be able to drag in an inventory of parts from emacs (or blech! vi) and then place them. Almost like dumping a baggie of the real (...) (22 years ago, 9-Sep-02, to lugnet.cad)
|
| |
| | Re: dragNdrop (Was: Ldglite must be faster)
|
|
(...) OK, I got multiline paste to work, but it just dumps them all in the same spot for now. I also experimented with pasting in a peeron inventory with quantity and all, but the part numbers don't always match up and the colornames definitely (...) (22 years ago, 10-Sep-02, to lugnet.cad.dev)
|
| |
| | Re: dragNdrop (Was: Ldglite must be faster)
|
|
I don't exactly have an algorithm for "spread out parts", all I really have done is to find an empty spot when dropping one part. Along a line collect up the intersection of all bounding boxes of other parts; find an interval that your part fits (...) (22 years ago, 10-Sep-02, to lugnet.cad.dev)
|
| |
| | Re: dragNdrop (Was: Ldglite must be faster)
|
|
Happy day... inspired, I learned how to implement window drag & drop in BrickDraw3D, and made part list and part viewer windows send each other a string (part id). Still no dragging into a model, but, it's a start. For the curious, I made (...) (22 years ago, 10-Sep-02, to lugnet.cad)
|
| |
| | Re: dragNdrop (Was: Ldglite must be faster)
|
|
(...) Are you still keeping the SourceForge CVS archive up to date? I'm curious what the dragNDrop code looks like on MacOS. I suppose it's different for OSX though. (...) I take a bunch of different drop/paste 'protocols' on the Windows version and (...) (22 years ago, 10-Sep-02, to lugnet.cad)
|
| |
| | Re: dragNdrop (Was: Ldglite must be faster)
|
|
(...) No, it's not up to date because I don't have broadband without firewall. Here's all I had to write. Mac Drag Manager calls are the ones with :: global scope. A lot of magic is hidden in the base class constructor (LDragAndDrop) and more magic (...) (22 years ago, 10-Sep-02, to lugnet.cad)
|
| |
| | Ldraw DLL - Was: Ldglite must be faster
|
|
(...) I'm not sure why, but this popped into my head last night. I think perhaps it may not be all that hard to do. The basic ingredients are already there in the winOffScreenStart() function of ldglite. I'd just have to convert it to use the hDC (...) (22 years ago, 1-Oct-02, to lugnet.cad)
|
| |
| | Re: Ldraw DLL - Was: Ldglite must be faster
|
|
"Don Heyse" <dheyse@hotmail.spam....away.com> skrev i meddelandet news:H3B7E1.BAs@lugnet.com... (...) On second thoughts, it might be better to pass the DIB as the rendering surface, but I don't know if this is easily done from VB. (...) If all the (...) (22 years ago, 1-Oct-02, to lugnet.cad)
|
| |
| | Re: Ldraw DLL - Was: Ldglite must be faster
|
|
(...) I haven't looked at WinHandles in awhile, I don't have a strong preference for which way we go. Of course, if we choose right, we'll get some drawing parameters 'for free' -- I'm thinking (trying to remember) of window size, user-defined (...) (22 years ago, 3-Oct-02, to lugnet.cad)
|
| |
| | Re: Ldraw DLL - Was: Ldglite must be faster
|
|
(...) I'd have to go look it up - bitmap/DIB handle, hDC, hWnd. One of those. (...) There are some options - like polling mode, background color, wireframe mode, etc, etc - that aren't duplicatable within an LDraw file. (...) That sounds more like a (...) (22 years ago, 3-Oct-02, to lugnet.cad)
|
