To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.cadOpen lugnet.cad in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 CAD / 8605
  Ldglite must be faster
 
I think we need a tool to search for parts like the one comes in mlcad. (22 years ago, 2-Sep-02, to lugnet.cad)
 
  Re: Ldglite must be faster
 
(...) You're right, of course. Ldglite needs to be faster, and it would also benefit from a nice parts searching tool. Do you think you could elaborate a bit on the particular features of the mlcad search tool that you like best? For example does (...) (22 years ago, 2-Sep-02, to lugnet.cad)
 
  Re: Ldglite must be faster
 
I prefer to use a integrated list part program. (...) (22 years ago, 2-Sep-02, to lugnet.cad)
 
  Re: Ldglite must be faster
 
(...) (22 years ago, 2-Sep-02, to lugnet.cad)
 
  Re: Ldglite must be faster
 
(...) That's odd. I use it every day and I have never experienced any problems at all with it. /Tore (22 years ago, 2-Sep-02, to lugnet.cad)
 
  Re: Ldglite must be faster
 
(...) Make sure you've got the LDRAWDIR environment variable set, pointing to your main ldraw installation. LDList works great, I use it all the time. It indexes the part names, keywords and categories. I should get off my butt and implement (...) (22 years ago, 2-Sep-02, to lugnet.cad)
 
  Re: Ldglite must be faster
 
"Don Heyse" <dheyse@hotmail.spam....away.com> skrev i meddelandet news:H1tH93.DFA@lugnet.com... (...) doesn't work... Does anyone know you can press CTRL-C in ldlist and paste the part number in any other (text) editing program? It also implements a (...) (22 years ago, 2-Sep-02, to lugnet.cad)
 
  Re: Ldglite must be faster
 
"Eduardo Vazquez Harte" <eduvazhar@terra.es> skrev i meddelandet news:H1tJ88.IxF@lugnet.com... (...) To the contrary, it does work (in Windows), IMO quite well, but it's a bit leaky, and needs to be shut down now and then, as it (more or less) (...) (22 years ago, 2-Sep-02, to lugnet.cad)
 
  Re: Ldglite must be faster
 
(...) Your right now it does thanks a lot Steve. Hope I make next step in less time than the first step of a model I'm making as a test with ldglite with ledit mode. (...) (22 years ago, 2-Sep-02, to lugnet.cad)
 
  Re: Ldglite must be faster
 
(...) Well, all the rendering functionality of LDView is in its own library, but I made it a static library when I added my experimental screensaver support in order to get rid of the requirement of multiple files in the Windows system directory (...) (22 years ago, 2-Sep-02, to lugnet.cad)
 
  Re: Ldglite must be faster
 
(...) I'd say it looks like people are indeed using it. Apparently it works well enough that they haven't found the need to ask questions. (...) Looks like Steve knew about the drag n drop peatures. What's involved in implementing the receiving (...) (22 years ago, 3-Sep-02, to lugnet.cad)
 
  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
 
(...) I don't have all the information handy, I've misplaced the correspondence on the subject, but here's what I can piece together: The basic thing is the WM_COPYDATA Windows message is being used to pass data between two programs. LDList is the (...) (22 years ago, 3-Sep-02, to lugnet.cad)
 
  Re: Ldglite must be faster
 
"Steve Bliss" <partsref@yahoo.com> skrev i meddelandet news:7ir9nug2rp1shdk...4ax.com... (...) Interesting. Must be some undocumented Windows behaviour - the WM_COPYDATA message is described as _the_ way to do inter-process communication (in fact, (...) (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)

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR