Floating windows..

[Kagehi]

One 'big' addition to a program I use will include the ability to spawn windows of one kind or another. Problem is, the developer doesn't have a clue how to manage it and I am afraid of waking up tomarrow to find that a less than useful compromise will have been implimented instead. While quite a few of us are programmers that use this application, few of us know C++ and even fewer know enough about C++ in this case to suggest a solution. I am one of the former, having almost no experience with C++ at all. I am however willing to try, if it means avoiding another sub-standard solution.

Basically, I need an example of a something like the tool windows in Painshop Pro and others work. The ones with smaller than normal title bars and hide themselves when you are not changing the settings on them, *and* above all else, how to keep them 'above' all other applications, including the one they belong to. It also needs to be able to support the clients own custom text and imput windows, since one use for this will be to have the auto-hide disabled and allow for certain text to be funneled to the window and user input sent back, with something preappended. This is the minimum functionality needed. Things like allowing it to hide itself when the main window it is tied to is not visible, because they switched to another one, are likely a lot more trivial, as would be 'dock in window' and 'dock to side of client'. I can probably manage to code those features in, even with my limited skills, given a basic example of how such a window would work in the first place.

I plan to keep googling, on the off chance (ha ha!) that I can actually find a premade example some place, but if anyone knows of one or can give me some decent hints how to go about this....

Thanks for any help you can give.

[JohnCz]

Floating windows are usually created as toolbars. You can also use dialog bar as a floating toolbar. There is plenty examples about dialog bars.

Having dialog resource as a toolbar you can easily maintain other controls as well as changing their attributes.

From all approaches this seems to be the easiest to implement.
Use ShowControlBar to toggle bar’s visibility.

[Kagehi]

I considered that.. The program already has one of those in it for one feature, but the dialog bars docking behaviour seems a tad buggy... When accidentally dropped in the middle of the window, it tends to try to dock to every corner at the same time, instead of restricting itself to the top or bottom edge. We still haven't figured out what the heck the problem is with that.

In any case, I did find an example at:

http://www.codeproject.com/wtl/wtlsnap.asp

for snapping windows, but these are internal MDI windows. The application we need them for is MDI, but we badly need an SDI type that can float or be snapped to the "outer edge" of the main window, not the inside, and yet has the same behavior of staying 'above' other applications. Even better would be to replace the 'pin' with an 'open book' icon, for the existing behaviour, then use the 'pin' icon to switch it between MDI and SDI, so it can either be docked to the outer edge or withing the main client as a normal MDI window. There seems to be some confusion of how or if you can mix the two or, more problematic, even if you can switch the behaviour between the two. This is one of those cases where I know the behaviour I want and am 99% sure it is possible, but I just don't know how to get all the pieces to fit. It doesn't help that the only copies of C++ I have to work with are Visual C++ V4.0 and GCC. lol Just getting a window to display at all in C++ is a major success for me.

But seriously, being able to 'see' or 'feel' how the pieces should fit isn't good enough. I wish it was though, it would make writing code a lot easier. lol Worse, most of the coding I have done myself has been with VB, and that requires you to fight the controls tooth and nail to do anything different than VB's default behaviours. Worse, some 'possible' things, even in C++, are nearly impossible to accomplish. Like actually using the Edit/Runtime modes for controls in your own application. I mean, a vast number of them have drag handles and other inbuilt features for their 'edit' modes, but the means to turn it on for a containers goes way beyond undocumented. Using it in VB requires coding something in C++ to impliment it, but since you can't find documentation explaining how the **** to even do it in C++.... Anyway, enough ranting. lol I have seen the behaviours I need and have a sense 'how' they should all work, but dialogs probably won't cut it, especially since some of their behaviours are not what I want, like docking in a form, instead of acting as another window.

Maye I am just thinking way to far outside the box MS wants everyone to play in.

[JohnCz]

I do not know anything about bugs in dialog bars.
Maybe 4.2 version of VC++ is a problem.

Floating only toolbars are easy to make; it is just a matter of style. Docking outside of the main frame window or child window of the MDI app is something you would have to implement.

Do you have any example application that behaves exactly as you need?

There is nothing that cannot be done in Windows; it is a matter of time and code investment.

[Kagehi]

Actually, 4.2 is the version I have. As far as I know the guy that developed the client I am trying to help with has the latest pre-.NET version. Unfortunately, since the program is commercial, we don't exactly have access to his code to see what might have been messed up with the dialog bar. I suspect however that the basic MFC code gets confused when it isn't clearly near the top or bottom and tries to incorrectly dock to both. It also becomes really hard to get it back where it belongs when it goes wrong. If you download the client from here: www.gammon.com.au/mushclient , then look at the bottom of an open world. There is a grey bar over the standard status bar. If you click on and drag it to the middle of the window, it will suddenly cover the entire client area of the main application and shove the text window to one side. Getting it back where it belongs is problematic at best. For now we live with it.

As for an example application that has all the behaviours I would like to see for the specific windows I am trying to create a demonstration of.... Nope. I am afraid not. I did some experimenting with a simply ActiveX gadget, built in VB6, which used some tricks to find the main window for the client, then through some APIs got the size of the window and docked itself (even resizing or minimizing when the client did), but that was only a test to see if I could create something that could substitute for it, until real ones where implimented. It kind of worked, but sort of didn't. Having to test the window size every x cycles, instead of simply having it respond to the clients own resize events, was a big drawback. Actually getting that information from inside the ActiveX I made would have required some complex latch into the system events which could crash the entire machine if not released properly. Bad idea imho...

Anyway. I guess an example that uses one of more MDI windows, but allows you to 'pop' one of those windows out of the MDI and into a SDI mode, so you can move it next to the 'main' window would be a 'major' step in the right direction. Everything else is relatively simple additions of a few behaviour and client integration that the developer could easilly manage. The main problem with suggesting additions though has always been convincing him that some things are possible. We have been fighting for this one for nearly a year, in any form. Personally I would prefer the most dynamic and adaptible one possible, not just, "It works, so stop complaining".