hi, i know this is a more advanced question - but i was just wondering... like viusal basic, u can drag and drop buttons on a form, i was wondering what they do so if you double click the button the code editor will pop out so you can write code for that button. and when you compile the code the button will do what you wanted it to do. does anyone know how they do this or have tutorials on making visual editors? thanks for any help, =)
Posted on 2001-04-03 17:23:00 by hehe
Not many people have written a visual editor. I've yet to see an open tutorial or documentation on making a visual editor. However, Ernie does happen to have an article written by Matt Pietrak (however spell) for win 3.1 that makes a mini dialog editor. Rainbird also has one, his is based on Delphi, and uses a 3rd party control to expose delphis RTTI through an inspector (unless he wrote the designer and inspector himself). I've go my own visual editor thingy already in the works and I wrote it from scratch in win32 api (after discovering how little a Delphi Based control for the same will help me in my situation). Here's the trick for how VB does it: each event maps to an API message... WM_ACTIVATE = Form_Activate, WM_LBUTTONDOWN = Control_MouseDown etc. I do not think that custom events use WM_USER+X messages. They use IConnectionPoint which is a COM callback. If you want to write your own Visual Editor from Scratch, your almost on your own. I write a post in an erlier thread about resource editors describing how I achieve my Visual Editor, but no source. I don't think I plan to release my source for it, but I will eventually release the editor. I'm working on a custom component architecture (why I started from scratch). This targets Asm Programmers primarily, but will also work with C/C++ or whatever. How? don't know. I have an IDE to finish before I worry about that. Thanks _Shawn
Posted on 2001-04-03 17:52:00 by _Shawn
as you've been making it, what are the harder parts of making one? i know the syntax highlighting has to be hard, i cant even think of how i could make it work right =(. i know delphi pretty well, this is the language i want to make my editor in. i'm not sure if i will be able to or not though =(.
Posted on 2001-04-03 18:58:00 by hehe
_shawn, The RTTI (Run-time Type Information) in Delphi is included with all Delphi apps if they use any VCL portion. This is free information with Delphi. No need for 3rd party controls. Even if one does use a third party control, they usually access the RTTI. Borland includes a little known unit that is being used for the Visual Designer. And, since everything you do in Delphi is object oriented (unless you skip the VCL), the RTTI is there to use. You can inspect all objects at runt-time. Eventually, when you go deep enough, you'll find the API's that Delphi calls for you. The best example I can give you is Delphi itself. Delphi has been programmed in Delphi. What more can I say... How can one use this knowledge? Well, since you can create objects (all objects including Windows controls) at run-time, you have full control when, where, and how you create them. For example, create a window, then when a user drops a control on the window, track the position and other details and create another control at run-time. There are also many VCL components that you can buy/purchase that will give you that feature more or less.
Posted on 2001-04-03 19:09:00 by rainbird
Well, in VB case, I believe VB subclasses all those controls and handles the messages itself. So when the user double-clicks on a control, VB is notified of the event first and handles it appropriately. The problem is the menu. Since the "form" in design mode is a child window, it cannot have a menu. VB chooses to paint the menu itself, emulating the real menu. Dragging controls require differentiation between left mouse click and drag. Within your WM_LBUTTONDOWN handler, you must call DragDetect to verify whether this mouse click is the first step of a drag.
Posted on 2001-04-03 20:21:00 by Iczelion
Rainbird, Perhaps my communication isn't exacting, but I'm well aware of what you described. I began using some components in the past and found limitations which I address by creating my own designer from scratch. Perhaps you feel strongly about the way you're doing it. That's Great. Perhaps I don't have the vast knowledge you do (since I've only been programming Delhpi since December) but then, perhaps you don't have the same needs as I so you don't see the same limitations I do. That's fine. We all start somewhere (even with new languages) and we all experience different limitations or situations. But we're all programmers and in the end, we'll have a solution. You, me, everyone. The bottom line is that what you're doing suits your needs. What I'm doing suits my needs. I'm an R&D programmer professionally. My job is to research solutions and develop the best solution for the need. I'm still evaluating my options and I'm in no way telling you how you should evaluate yours. Perhaps our communications just clash with each other. I am, however, new to Win32 Assembly, as well. For a pure designer, I must write my own. However, for my scripting language, I'll likely use a prebuilt form designer component. Perhaps I'll just reuse the one I already created. However, for purposes of OCX, it's the easier alternative to not figure out how to impliment a control host in assembly and just use one already done. Depends on my needs. I have other goals to accomplish first for my Developer Tools Suite. I'm not the best COM programmer. Hehe: The biggest challenge you'll encounter with making a visual designer, is probably providing it the ability to support custom controls. Whether they are custom Windows controls, OCX Controls, VCL controls, PowerBuilder Controls or whatever. It's easy to hardcode support for any known control that you want. But allowing the user to create and the designer to support custom controls of any type, is the proving challenge. Now, converting that support into a Resource or Assembly or whatever language is also the other part of the challenge. Iczelion wrote a great tutorial on syntax highlighting. However, the approach that I have taken (and RainBird) in our Delphi based app is to use a 3rd party Syntax/Memo control (not to mention the Assembly Studio project and VisualASM -- which I use a lot >> I like it's simplicity). There are times when you want to create your own from scratch, and other times when it's good to use prepackaged components. Knowing when to do which is a call you must make based on your needs (I'll explain later). Also, if you want to add support for auto-completion of procs and paramaters and whatever, unless you want to write your own, a good 3rd party control will work just fine. The one I'm using just requires a list of strings and it will populate the popups with that info. I choose to ease my burden with my object model. The IDE has a collection of functions, Macros, parameters for each, return types and other related info which is gathered a specified time and once the need arises to use it, the info is already in a list and is rather quickly populated into the popup list that will help you with your options. Since my IDE will have the potential to support other syntaxes and languages, I have special considerations for my parser and it's associated extensibility. You may not have such needs. But I don't parse for my functions or parameters on demand, they're already parsed. Even if I include all the windows and sdk inc's, my app uses very little memory and almost negligable timings to return them once required. Of course, everyone uses a different technique. I just want to minimize threads and unneccessary parsing. Whichever route you take, just consider what functionality you want and which one's you want to implement in your own way (i.e. syntax highlter, form designer, debugger, performance analyzer, compiler, etc) and the one's you don't plan to customize in such a way tha
Posted on 2001-04-04 18:47:00 by _Shawn
For the VB case, the active X controls you place on a form (the only type of control VB directly handles) is a live running activeX control as soon as you select and place it. This can be quite disconcerting if the control does something particulally visual, like a moving gif, because it will run right in the VB form designer as soon as you place it there. Actually, a full professional control reads the type of enviroment it's in, and it can tell if it's in a running program or development mode. The IDe has a property called user mode, and if there is no user, there's a designer there by default. So the savy activeX control developer makes the control *appear* to be dead in the designer. Since it's a live activeX control, the form designer can easly use the event mechanisms of that control to pop up a code section if the control is clicked. Likewise, the running control's properties are read out to fill in the property browser, and the running control also is in charge of storing ('persisting' in COM-speak) the changed properties in the property bag (ie, the text representation of control properties you find in the form.frm files).
Posted on 2001-04-04 23:29:00 by Ernie
Ernie, Much easier said than done... implementing it probly could be a little mid-trivial... _Shawn
Posted on 2001-04-05 02:48:00 by _Shawn