Well it took me two days of fussing around with this, but I think I did a pretty sweet job of wrapping up Entro-P's starting work into something robust and resuable.

I have essentially made an API like function that will transparently rollup dialog windows for you. Its to be used like a call to CreateDialogParam would be used (since its at the core of this "API").

Simply pass in needed parameters to get going, and away it goes.

Programatically all you need to worry about is including the lib, and programming the DlgProc(s) for resource items as you normally would!. It will do the rest.

It works fantanstically on Win98. And i have an early test on Win2000. So im hoping it will work well on all platforms. If there is a problem let me know.

As always, i have provided full source ;) . Its helpfull if you want to modify some internal equates (nicely organized at the top of one of the files).

Here it is, please give feedback!
Posted on 2003-04-16 22:48:12 by NaN
Here is the basic idea. The "NaN" window is rolled down since the cursor is over it. And the "Entro-P" window is Rolled up since the cursor is not there. Each window can be closed or Locked open.
Posted on 2003-04-16 23:09:27 by NaN
Hi NaN,
good work.

I have a bug report, and a suggestion:

the bug: when the dialog is rolled up, and you go to press the close or minimise buttons, the window suddenly expands, thus moving the close/minimise buttons. I consider this a bug because it is not behaviour i would expect as a user.

the suggestion: have the roll-out speed adjustable, this would look quite cool, and make it similar to the Windows menus. Another cool idea (all my ideas are cool, ok?): as the dialog rolls out, adjust the opacity from 0 to 100%.
Posted on 2003-04-17 07:18:11 by sluggy
Sorry i programmed it do as such. I wanted it to unconditionally expand when the mouse is over it. I suppose i can limit the trapping area quite easily tho (to ignore the buttons).

As for the "rolling" rate, there is none. It doesnt actaully roll. It pops up. It would be alot more coding ( ALOT ) to do this feature for a little eye candy. If you wish to modify it to do so, i urge you to go ahead. But for my tastes this is all i wanted.

Thanks for the test tho, what system are you on?
Posted on 2003-04-17 09:17:05 by NaN

It works fine on my internet box running win98se. Nice idea for an interface.


Posted on 2003-04-17 09:37:41 by hutch--
Ya i like the self registering, and how it does so... ;)
Posted on 2003-04-17 16:34:08 by NaN
Thanks for the test tho, what system are you on?
Win2K Prof, SP2.

I agree, the eye candy would be much more work, but eye candy is cool ;) I might take a quick hack at it, see what i can do.
Posted on 2003-04-17 17:45:33 by sluggy
Eye candy sucks. Rollups can be nice, though... think photoshop or paint shop pro.
Posted on 2003-04-18 07:43:13 by f0dder
Thats why i upgraded Entro-P's starting work here. He did alot the How-To to show the concept, but i revamped it to make it behave univesrally and transparted to the programmer.

I hate AutoCad's way of managing layers (its GUI). Its takes too much time and clicking/list box searching to find the next layer your looking for. Our company has a zillion layers as our "office standards" and they can't be read through the drop-box since most of them have long names.

So im writing a "Pallet" like drop window that will display a sample picture, with drawn obejcts on them. Click on the lighting fixture, and voila, it puts you on the proper layer. Move the mouse away and start cading again. Basically One click layer selection (and no reading/searching needed).

I figure i will add a couple tabs to the dialog box as well, to offer a few more features.. but this is the general idea. And it runs along with why PSP offers simular dialogs for graphical development. Its quick and fast to find and make changes to settings...

Posted on 2003-04-18 09:00:12 by NaN
Man, my purpose for this seems to have hit the wall. To my surprise, there is no direct (or obvious) equivalent to a VB function in C/C++. Im trying to get the instnace of a running COM application (AutoCad), as it seems, only VB offers a function to do so (Very Puzzling).

This effort, personally, may have been in vain.
See Here: GetObject(, "MyCom.Application") if your curious.

Posted on 2003-04-18 11:58:46 by NaN
Hi NaN,

You might want to look at this :

Posted on 2003-04-19 22:42:57 by donkey
Thanx ;)

I actually found that exact link yesterday. It was one of the better ones, but still didnt hit the mark. I actually found a solution on the MSDN knowledge base, by searching on google with the line "Equivalent GetObject" ;)

I was surprised it worked! Search engines never cease to surprise me :grin:

I have it now working! But it opened another can of worm for me :rolleyes: , specifically with the nitty gritty of COM and what MS doesnt tell you about how COM works. This can of worms would never be noticed if i was using VB cause its in VB's very nature to cover up background crap! Longstory short, the interface retrieved is not a DUAL interface, and can not be early bound, leaving the slower way of binding method calls. The same way VB does it, late binding, which is far slower.

The irony is i can Create my own NEW interface, and it will suport EARLY binding. However this is a new instance, not an existing one im trying to link to with my program....

Anywho, i have these problems at bay now and im making good progress again!
Thanx for your help though!
Posted on 2003-04-20 00:08:01 by NaN
Ah well,

COM to me is like magic, nice to watch but impossible to understand :) I really have to take a look at Ernie's stuff some day. I found that place while I was looking for some stuff in VB on com because I can't seem to implement some interfaces in ASM, but now I have to learn VB :rolleyes: and I could never wrap my head around the backasswards syntax of high level languages (I seriously only know MASM). About the only com interface I have successfully used was to get the target of a shortcut and that was relatively simple but nearly resulted in insanity (actually the jury is still out on that one)
Posted on 2003-04-20 00:29:03 by donkey

COM is easy to understand. Kinda like DLLs they have a structure and format. They also have an API set that helps you do things (most of the time ~ as i just discovered).

Ernie did some fantasitic ground breaking in the topic, and is what i used to initially learn from, however, IMHO its very complicated in his layout. He had made provisions for alot of stuff that i have never done yet. Doing so makes his package very "rich" with other code etc., and tends to confuse otheres.

Japheth has done some great work in COM as well, IMO. I mainly use his style of COM programming. Is very simplistic and easy to follow. Especially now that he has written and revised his COM View 7 or 8 times now, its very usefull and will generate needed includes for you! Simply based on the programs registered in your registry!

Calling COM objects has become no more challenging than calling anything else. There is macros written as wrappers vf() and dm() "Virtural Function" and "Dispatchable Method:

invoke vf(pIFace, IFaceName, Method), Param, Param, Param


invoke dm(pIFace, IFaceName, Method), RetType, Return, Param, Param, Param

Thats it really! ComView will build the needed includes to work with these two calling styles!

If your intersted "COM" to the "COM" section ;) . Things have been slow there lately so its a good time to ask questions and learn.

Posted on 2003-04-20 09:49:51 by NaN