Gammon Forum : MUSHclient : General : Design mode (from the thread on external windows).

Register forum user name Search FAQ

Gammon Forum

Entire forum

MUSHclient

General

Design mode (from the thread on external windows).

Design mode (from the thread on external windows).

It is now over 60 days since the last post. This thread is closed. Refresh page

Pages: 1 2

Posted by

Shadowfyr USA (1,786 posts)

Date

Wed 25 Feb 2004 06:14 PM (UTC)

Message

For anyone interested, I finally tracked down how to change a control container (such as a window) from 'run' mode to 'design' mode. In theory all windows, even those in VB should have this property and behave by signaling their children to switch to design mode. However, the geniuses at MS apparently didn't think being able to change this property was useful. I guess they figured end users design applications, not applications that design forms or other applications. :(

Anyway, for those interested, this *seems* to be what is needed:

dispparams.rgvarg[0].vt = VT_BOOL;
dispparams.rgvarg[0].bool = FALSE; // Or TRUE for *run mode*.
dispparams.rgdispidNamedArgs = DISPID_PROPERTYPUT;
dispparams.cArgs = 1;
dispparams.cNamedArgs = 1;
hreselt = Object->Invoke(DISPID_AMBIENT_USERMODE, NULL, LOCALE_SYSTEM_DEFAULT, DISPATCH_PROPERTYPUT, dispparams, NULL, NULL, NULL);

VT_BOOL = 11
DISPID_PROPERTYPUT = 0x4
LOCALE_SYSTEM_DEFAULT - No idea.. It has something to do with the systems current language setting or something, but I haven't tracked down precisely how this is derived.

In theory, a VC++ class that you passed your VB window to could set this property and any controls you have on that window would automatically switch modes. You might need to tell it to turn on DISPID_AMBIENT_SHOWGRABHANDLES and DISPID_AMBIENT_SHOWHATCHING as well, but that depends on how VB's own control containers handle a change to the UserMode property. I really wish VB gave access to these things.. Sigh....

Posted by

Shadowfyr USA (1,786 posts)

Date

Reply #1 on Fri 21 Jul 2006 09:52 PM (UTC)

Message

Hmm. Some notes on this, since I went looking again..

Seems you can "cheat" and call:

obj.OnAmbientPropertyChange(DISPID)

Where DISPID is -709. That will make a single control behave differently, but could in some cases cascade the invoke for a container, with unclear results... Why does everything about how this works have to be so badly documented?

As for the original info, LOCALE_SYSTEM_DEFAULT can be replaced with NULL, if you don't care what "language" the client is using. The whole mess of code needed to get that parameter does nothing but find out if your using a different code page or language settings... Big bloody mess.

Looks like LuaCOM may support this as well, though its designed to obfuscate the interface a bit, using the standard obj.property method of get/put for properties. These "tend" to exclude "Ambients", which are needed for the above trick. And this of course assumes that ActiveX forms which support this exist, never mind buttons, etc... Got to do some more looking. ;)

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #2 on Fri 21 Jul 2006 10:05 PM (UTC)

Message

Something tells me, Shadowfyr, that one day you will get all this working, and on that day we will all have a big party. :)

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Shadowfyr USA (1,786 posts)

Date

Reply #3 on Sat 22 Jul 2006 06:01 PM (UTC)

Message

I certainly hope so. I have put a lot of time into it for no result, especially since it seems like the only other people on the entire planet that usually care about these things are... corporate clones, who can't give anyone else any advice on how to make it all work. :(

Posted by

Metsuro USA (389 posts)

Date

Reply #4 on Sat 22 Jul 2006 06:38 PM (UTC)

Message

Just start writing a book on it, or some such. By the time you find out how to make it work, you can make some money off it, for actually documenting it for people!

Everything turns around in the end

Posted by

Shadowfyr USA (1,786 posts)

Date

Reply #5 on Sun 23 Jul 2006 09:57 PM (UTC)

Message

Some one already did that... Guess what! The books is no longer in print, the online versions only make vague and inexact references to how it works and the source code isn't available. They might as well not have even written the book. :( Its almost as bad as trying to track down anything on "raytracing", that doesn't erronously, and in shear ignorance of the difference, immediately start babbling about OpenGL or DirectX.

Most of my past attempts, on nearly "any" subject, have been presented with useless information, usually in the following order:

1. The clueless. They didn't read of comprehend the post, came back with a standard reply about how X works fine for them, even when you just told them its completely worthless for your project. Tech support companies usually provide you with a form letter at this stage, which barely even relates to the subject and is copied from their "self help" section...

2. Peanut gallery. Tech support "usually" doesn't have this, but sometimes you do get one asking you, "Why in the world do you want or need to do that." In forums, this usually consists of them telling you that you are the clueless moron, because you think that none of the $100-$1,000 dollar products that don't "quite" solve the problem are in fact worthless too you.

3. Vacuous Narcissus Informationus. They still don't have a clue what you are talking about, they don't care and are completely scare of unique or different solutions, will go to great lengths to "explain" how to do something you previous described wouldn't work for your project, then whine when you tell them that they completely missed the point.

4. The rare Informationus Actualis. Sort of like being a cryptozoologist and actually finding the bigfoot carcus, this can induce a heart attack, which if you survice, you might eventually use the few scraps of knowledge you gained from the encounter to actually find an actual solution. This creature actually has some idea where to look, what you mean, how to fix the problem, but like bigfoot, all too often has secret pact with some major corporation, which demands that they only leave a few foot prints, a couple of blury photos and a vague sense that you might have been conned by a guy in a gorrilla suit.

Still, the later is "far" more useful than the others. ;) lol

Posted by

Shadowfyr USA (1,786 posts)

Date

Reply #6 on Wed 26 Jul 2006 05:37 PM (UTC)

Message

Update- Or, why MS sucks..

I downloaded this:

http://oaklandsoftware.com/product_compinsp3/product_3.html

Its an application that brings up a list of objects you can generate, then lets you play with them, including being able to create some of them in a mini-form in the program, in "design mode".

I discovered a few things. A) almost none of the objects in the comctl32.ocx, which comes with the OS, are properly registered, so you can't create them at all. This includes buttons. B) There is no "window", "form" or other similar object available anyway, so you can't create one without yet another library, like say wxLua. And C) MS doesn't bother to provide useful documentation of Design Mode because, drum roll please..., their own controls, during initilization, peek into the system registry to look for a licensing key. If the key is missing, you can only create them in "run time" mode, which means you can't move them or change certain design time characteristics. Basically, "If you can't create the control for design time, why tell anyone how to activate it?", is their theory. Instead, the object throws an exception, whose error code basically translates to, "You do not have a license to use this object."

What does this mean... Well, it means that design time is still possible, but I will have to do what I didn't want to, which is design my own custom dll, with its own classes of controls, and then any additional controls someone might try to add on later, "they" have to deal with the, "You do not have a license...", error. Basically, any way you slice it, no matter the language, I can't use MS' own activex controls. The only possible positive is that "maybe" the controls only look during initilization, so will behave when switched to design mode, but create in runtime mode. But since I still don't have a solution to switching them, I can't even test that. Worse, it might not matter, since the VB runtime controls may not be pre-installed, and they may not, if installed, correctly register all the controls for use directly through activex.

The whole point was to try to avoid having to code all the BS in C++ and limit the user to only "known" types of controls... :( And even if written in that, I am not sure if the design time drag handles, etc. are part of the ocx wrappers or part of the standard controls. If the former, then any dll/exe has to make its "own" handles and responses for dealing with that, which puts you right back in the realm of VB, where, since you can't access design mode, you have to invent fake code to make it "look" like its got drag handles and other features. What a pain in the #$#.

Posted by

David Haley USA (3,881 posts)

Date

Reply #7 on Wed 26 Jul 2006 05:43 PM (UTC)

Message

Somehow, it seems that this is almost desirable behavior, no? After all, I wouldn't want somebody to be able to go into the internals of my program by switching in and out of design mode at runtime. Sure, it's really annoying for what you're trying to do (still not entirely clear to me...) but maybe you're trying to do something that the system just really wasn't designed to do. That's how it looks to me, in any case, given the difficulty you've had and the various issues with COM etc.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by Shadowfyr USA (1,786 posts) bio

Date Reply #8 on Wed 26 Jul 2006 08:11 PM (UTC)

Message

You have used Visual Studio's Form Designer, right? You know, where you click a picture of a button on the left, plop it down on the form, then edit its properties on the right? That is what I am trying to duplicate.

And no, this is **not** something that the system isn't intended to do. Its a feature built into "all" control containers. VB and other development systems go to rediculous lengths talking about how to "check" if the container you place something on is in "design" or "runtime" mode, so that you can make it behaviour correctly in both environments. The problem is, MS doesn't, apparently, want you using your own application to develop forms. They want you to use "their" designer, so that you have to buy, "their" compilers, so they design "their" controls with an extra check, which tries to determine of you have a license to "design", not just "run" them. Third party controls, which are not part of those with VB, or VC++, do not look for that license key, so can be created in "either" mode.

Its a copy protection scheme, intended to make sure that you must have MS' software to design forms, not an inherent requirement of ActiveX or something internal to the system. I can for example use the utility to create controls from other companies, even in "design mode", just not those from the VB runtimes. The ones for VB, you have to create in "run mode", but its not clear if you can then "switch" to design mode after.

Now, one solution is to use the form designer supplied with .NET. However, that would require everyone to not only install LuaCOM, but also .NET, and some older OS's, like 95, which can run Mushclient, can't run .NET. And of course, since I would be using MS' designer, I would be stuck with their behavour. My preference would have been to design the entire "designer" in Lua, since that would allow me more flexibility. Instead, I may be forced to write in C++ to do it. This hardly makes it something the system "doesn't allow", it just makes the means to get there unneccessarilly complicated and time consuming. But, people "have" done it. I have read articles from people that have, but none of them give any actual code and one involved a dll to be instanced in VB, which provided the feature. The book is out of print, the name of it I don't remember and the guy that wrote it has a irritating habit of using the name Patron for his examples, in every book he ever writes, so trying to find the code using Google won't net you the code from that specific book.

Mind you, it can still be done, with some limitations. For example, one textbox control doesn't let you set it for multiline in run mode, only while in design mode, and there is no way to create a version with multiline already set. Creating a basic window should be trivial, with the right code. Creating some other things..., a bit harder. But you have three options: 1 - manually code the layout into your script, i.e. "obj.top = 0, obj.left = 12", 2- use my idea but manually "design" the layout, i.e.:

<form>
  <button
     top = 0
     left = 0
     ...>
  </button>
</form>

then have a block of script to load and create all the needed stuff, OR 3- use my idea, entirely, where a plugin can let you create, place, then save the layout of the above, so that the other block of code can read it in and produce the final result.

All are possibilities. 1 and 2 are hardly coder friendly, never mind easy to manage for someone only learning how. The last one "should" be possible, but MS' rediculous paranoia and copy protection schemes keep getting in the way.

Is that clearer?

Posted by

Shadowfyr USA (1,786 posts)

Date

Reply #9 on Wed 26 Jul 2006 08:21 PM (UTC)

Message

Oh, and just to prove my point about how this works. The page I found explaining it, also explains how to "fix" it, if you are using the new Visual Studio .NET. They suggest:

1. Installing VB6.0, which then also installs the licence key.

or

2. Look on your .NET disks for a file called in xtras\VB or something like that, called VBControls60.reg, and which applies the needed "patch" to the registry, to allow the old VB 6.0 controls to be loaded and used in .NET's designer.

In other words, their copy protection scheme, to prevent anyone else from using their controls in another compiler, also screwed them up, when they switched to the .NET setup. But I can hardly see telling people to hunt down a file that isn't available online, to patch the registry with something they may not be legally entitled to, according to MS, so that they can "most" use "some" of the controls that are supposed to be available through it, in a Mushclient plugin based designer.

Posted by

David Haley USA (3,881 posts)

Date

Reply #10 on Wed 26 Jul 2006 08:22 PM (UTC)

Message

If you're talking about the form designer that e.g. VB uses, then sure, I've used that. My point was that I didn't think that is meant to be accessible at runtime. I would not want users of my programs to be able to hook into the design mode and start messing with things.

I'm a little unclear on what exactly you are referring to by "control". Do you mean the OCX controls? Or something else? I think the runtime/design mode distinction isn't an inherent property of a Windows control per se, but rather something that is part of Microsoft's development environment -- and you don't have to use it. For example, I have written controls for ATL/WTL that (as far as I could see) had no runtime/design mode. In fact, their positioning was done manually, not using a form designer.

I think I'm starting to understand your intentions, but I still really don't understand why you think this should be so easy. What you're describing seems to be a full-blown, completely dynamic runtime GUI environment, built inside Windows, that is fully accessible from all scripting engines, without writing a line of C or C++. To me it seems like that is a lot more complicated than you make it sound.

I'm also unclear on which hooks precisely you need to talk to the host (is there even a host?) application. It seems to me that everything you said about specifying the form layout is basically incidental; the essential part of what you're looking for is how to hook into a running application's form and mess around with it, no? Once you can do that, parsing a layout file and turning it into an actual control layout is another problem (which again I think is a little more complicated; whole libraries have been devoted to that kind of thing, not just little scripts). Is this correct?

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Tsunami USA (204 posts)

Date

Reply #11 on Wed 26 Jul 2006 11:19 PM (UTC)

Message

Not my speciality, but I feel so much of your pain... :(

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #12 on Thu 27 Jul 2006 05:48 AM (UTC)

Amended on Thu 27 Jul 2006 05:49 AM (UTC) by Nick Gammon

Message

Quote:

... almost none of the objects in the comctl32.ocx, which comes with the OS, are properly registered, so you can't create them at all. This includes buttons ...

I think you are confusing "control" with "OCX control" here.

You can write a small, compact, Windows program that does not use OCX controls (or COM) at all. An example is the custom external status bar I released a while back:

http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=4951

When you are using Visual Basic, it is making it easy to use by hiding a lot of the low-level operating system calls needed to make it work, such as routing events to it from your main event loop.

A simple button in a simple application is simply a "child window" of the main window. However when you add a button using VB you are actually doing something somewhat more complex, you are creating an instance of an OCX "button control", which has methods for accepting events (eg. the "design mode" you talk of) and returning events to the caller (eg. someone clicked on me).

For example, in some parts of MUSHclient I need to move buttons, for instance when you resize some windows that have buttons along the bottom, so the buttons stay centered.

I don't call some sort of "button property" to do that, I simply call MoveWindow (a low-level operating system call), passing it the window "handle" - which is a 32-bit number Windows assigned to the window when it was created.

See:

http://www.answers.com/topic/movewindow

This isn't copy protection - although that wouldn't totally surprise me - it is simply that you are trying to take VB for a walk to somewhere it is not designed to go, namely applications that weren't primarily designed to interface with VB.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Shadowfyr USA (1,786 posts)

Date

Reply #13 on Thu 27 Jul 2006 06:31 PM (UTC)

Message

Sigh.. Here is the thing. VC++ also has a "form designer". Guess what? It works the same way as the VB one. If you look at books on "designing activex controls", mind you're right in that isn't necessarilly the same situation as non-activex controls, there is always a few comments on how to a) detect changes to user_mode and how the control needs to handle it, if you want to use it in the design environment.

Looking at the API, I suspect what we are looking at here is that when designing a "window" for ActiveX you need to add:

Usermode, and code to fire the event for it to the hosted controls.

Uidead - Provides the activeX equivalent property for EnableWindow.

Showgrabhandles - Something you need to add to it, to provide a way to move it around, when in design mode.

So, you're right. Standard controls don't appear have these (or at least not based on what I can see in the API), but I wasn't trying to work with "standard" controls, I was trying to work with ActiveX controls, which require these properties as part of the full implimentation of behavour. Mind you, they might, if someone is lazy, not support them.

This ironically both simplifies and complicates things. Its simpler because it should be possible to code an ActiveX based window that works as its supposed to, along with other controls, but it complicates things, because its no longer as simple as using the "existing" ActiveX controls on the system, which use copyprotection to prevent you from using them the way I want.

Shows you how bad it is to assume that the inheritence in the API would include basic stuff like design mode support. :( The irony is, VB forms "do" host activeX properly, so do have these properties, but because of MS' copy protection scheme, the only way to do this is to use EnableBlah... directly, which doesn't "always" work the same way as Uidead for ActiveX controls, and bloat the VB app with code to "mimic" the grabhandles the controls themselves already impliment... Nothing like having to duck tape a wrench to the end of a 50 foot pole, to get to a water valve, because some clown put a padlock and electric fence on the only gate into place its located...

Posted by

David Haley USA (3,881 posts)

Date

Reply #14 on Thu 27 Jul 2006 06:47 PM (UTC)

Message

Are you sure the VC++ form designer is actually doing the same thing as the VB form designer? I'm not convinced it's really the same thing, even though they have the same user interface. For starters the VC++ one is a lot "downer and dirtier" than VB -- as is usually the case, VB hides an awful lot of things from you.

Maybe what you're trying to do might work if the C++ application basically did everything that VB does and behaved like a full ActiveX application. Maybe; I'm not at all sure. But that's assuming a lot about the behavior of the host application; potentially assuming too much. (I believe that MUSHclient, for instance, uses straight MFC, not the new-fangled ActiveX stuff.)

Basically a "standard control" is, fundamentally, just a window within a window, like Nick said. There isn't really any question of design mode vs. runtime mode. I think all of that stuff is a rather different specification, perhaps only for OCX or ActiveX.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

55,098 views.

This is page 1, subject is 2 pages long: 1 2

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Comments to: Gammon Software support
Forum RSS feed ( https://gammon.com.au/rss/forum.xml )