Overlay dialog - How to do?

[BOB MECHLER]

I would like to create a dialog that would be transparent except for the controls, frame and caption bar and act as a child of the parent dialog. When I set up a dialog background bitmap one time I got nothing but the desktop inside the frame of the dialog until I corrected an error but can't seem to find an example of one that was done on purpose and yet had controls (textboxes).

Another use would be as a help screen that could be called and overlay a real screen with more help than is usual in a tool tip. I could show several help boxes in context pointing to several fields at the same time. The help could even be a scrollable region this way or a treeview with related topics this way. Right now we are popping up pdf's based on the field the user is in or for the entire program from a menu item.

Bob Mechler

[Chris Boss]

Regions.

The SetWindowRgn API function allows you to set a region for the dialog.

They key is in creating the region properly.

You should be able get the client area rectangle and then enumerate all the controls and get their rectangles and from this generate a region which only includes the border/caption and controls. Then set the window region and Windows will take care of the rest.

This should work on any version of Windows (95 to Vista).

[Michael Mattias]

would like to create a dialog that would be transparent except for the controls, frame and caption bar and act as a child of the parent dialog.

Wouldn't it just be easier to CreateWindowEx or CONTROL ADD the controls needed at the time they are needed?

Or for that matter, create them hidden, and show/hide as required?


MCM

[BOB MECHLER]

Sure I could and have many times done exactly that.

Just playing around with ideas for two things I want to do.

We have a certain program with 25 fields where the tranaction code entered can have 15 different combination of field and field rules based on the code entered. I thought it might just as easy to put fields associated with a particular transaction code on an overly with it's own dialog callback to handle the specialized business rule for the fields. In some cases a field would be restricted to certain levels of security or hidden based on who is running the program. Instead of showing and hiding a group of fields it just seemed better organized to separate functiality to it's own overlay dialog and callback.

In creating a tab control you create a popup style dialog for each tab and each has it's own callback right. This would be just a variation on that theme. It's easier to show and hide the whole dialog than show and hide individual fields. (At least less typing)

The other application of an overlay dialog would be for much more intense help where the user could customize help for their own employees to augment the help we would supply. Customer help can now be defined using Word,NotePad, Pdf and placed in a directory where the current program name will call the help file for the current program on screen.

In demos it would also be useful to have an overlay screen that the user could walk through a transaction on screen by clicking next or previous and have as much help available as needed, whether we write it or they do.

Right now some people might use Word and screen capture to create documentation based on screens that may change and documentation that soon goes out of date.

Other programs often have links to websites to get the latest help information rather than continually rewriting the manuals.

We have one or two people who do nothing but manuals. It might be argued that printed or even program wide manuals .doc files are not referenced as we might expect.

How often do we say Read the Manual!

Bob Mechler

[Cliff Nichols]

How often do we say Read the Manual!

Hmmmmm....I have been known to mutter that under my breath (or plain yell it after a tech call) probably on a daily basis!!!!

Usually its the same scenario of "I just got this system...how do I...<insert typical question here>????"

It just gets Maddening sometimes, answering the same questions over and over, and people will NOT read if it's more than a couple of words explanation.

So Bob, I totally get what you are trying to do, and why. (I too have run into situations, that the user wanted to set my program to only show certain tools to the end user, and not show full capability unless you were an admin user of sorts.)

In this kind of situation, I have resorted to Instructions show on the bottom of the screen (resize able due to customer input) and each dialog / window post instructions, how to use the tool (although I would think the layout would be "Self-Explanatory" and for locking out users....I plan on show/hide or enable/disable menu options, so the layout can work the way they want it.

So unless you are willing to write and rewrite multiple versions of the same software, AND the documentation that goes with it....I think you have the right idea....just the wrong way of implementing it.

Or did I misunderstand, and you are trying to "Mini-Demo" how to use a tool at the time the user activates the tool? (or to a further extent demo each tool?)

[BOB MECHLER]

Mini-Demo, situational popup. If I could get a generic tool built that would look at the transaction that was typed in and refer to a table of help hints that could then overlay the screen letting everything show through except the help boxes that might be pointing to several different fields on the screen.

There are many business rules out of sight and there are always new computer operators who take up valuable managerial/trainee/help desk time.

We see this kind of thing with Intellisense but to me, unless each choice in Intellisense comes with links to full descriptions with a full compilable examples I find it almost useless as a learning tool.

How many books show screen prints with many info boxes pointing to code or visual objects with explanations.

We comment our source code ( or should) but don't have a commenting system about how the program runs where the comment is easily visible at the point of interest instead in a massive help file with a table of contents.

One product I have used called DataEase had a field level and form level help feature the programmer or the customer could fill in.

We have 8 long integers for each control. Maybe I could use one of those slots for a help Id. Hmmm..

Bob Mechler

[Chris Boss]

A possible concept which may be useful, would be to use a ToolTip control (possibly even a superclassed version with your own features) which will display over any controls you need. The tooltip could then use the layered window feature of XP and Vista to alphablend itself so the background can show through.

The tooltips can then auto display itself over controls and then check the control for an ID number (using DDT you can use the CONTROL SET USER command to define an ID number and CONTROL GET USER to retreive it. Then have the tooltip read a data file (or a data array in memory) with the text for each ID and then display it.

Regions can be used with ToolTips (or use the balloon style) to display a non-rectangular window. You could create your own Info Boxes customized to look the way you want.

[Chris Boss]

I posted an example of layering a tooltip control in the source code forum.

http://www.powerbasic.com/support/pbforums/showthread.php?p=287910#post287910

[Michael Mattias]

>I posted an example

Style points question...

SUB AddTool(BYVAL hToolTip&, BYVAL hDlg&, BYVAL IDNum&)
    LOCAL TT AS TOOLINFO, hCtrl&, RV&
    [B]CONTROL HANDLE[/b] hDlg&, IDNum& TO hCtrl&
    IF hCtrl&<>0 THEN
        TT.cbSize=SIZEOF(TT)
        TT.uFlags=%TTF_IDISHWND OR %TTF_SUBCLASS
        TT.hwnd=hDlg&
        TT.uId=hCtrl&
        ' TT.rec=
        TT.hinst=GetModuleHandle(BYVAL %NULL)
        TT.lpszText=%LPSTR_TEXTCALLBACK
        TT.lParam=0
        RV&=[B]SendMessage[/B](hToolTip&, %TTM_ADDTOOL,0, VARPTR(TT))
    END IF
END SUB

Why do you use CONTROL HANDLE and SendMessage in the same function?

You could use CONTROL HANDLE and CONTROL SEND if you wanted a 'DDT' solution; you could use GetDlgITem and SendMessage if you wanted an 'SDK' solution.

I notice you use CreateWindowEx and SendMessage when creating the tooltip (instead of CONTROL ADD and CONTROL SEND); so CONTROL HANDLE is the only 'DDT-specific' syntax in the whole post.

Then again, the demo program itself uses DDT style to create the screen.

I would think you would want to use SDK-style in the 'library' portion; that way PB/CC users could use the code on whatever windows they might create.


(In a pure interpretation, CONTROL HANDLE is only guaranteed to work with DDT-created screens and controls. Yes I know it "works" with anything in the current compiler versions)


????

MCM

[Chris Boss]

I prefer to post DDT based code on the forums since the majority likely use DDT.

As far as using SendMessage, rather than CONTROL SEND, I prefer to call CONTROL HANDLE once to get a handle and then use some API calls like SendMessage, because using CONTROL SEND is redundant since it has to convert the form handle and control ID to a handle internally and if I make multiple calls which require a control handle, it is simpler to just get the handle once and call the specific API. Certain APIs are used quite often (ie. send message) and this should not pose a problem for DDT users.

Lastly it is not a sin to mix DDT and API calls. DDT is based on the Dialog API's and while there may be a few quirks that some SDK style coders may not like about DDT, it is completely compatible with the API.

When using DDT commands, I consider the actual API's it likely calls and I consider the ramifications of using the DDT command versus the API directly.

For example, CONTROL SEND must call GetDlgItem internally to get a controls actual handle. If multiple messages must be sent to a control, it is redundant to do this, so I use CONTROL HANDLE to get the handle and then use SendMessage. In some instances I am so use to this, that even if my code sends only one message I may still do this.

[Michael Mattias]

For example, CONTROL SEND must call GetDlgItem internally to get a controls actual handle

Actually, no it doesn't 'have to' do that. Maybe CONTROL SEND is implemented with the "SendDlgItemMessage" WinAPI function. Or maybe a handle for all DDT-created controls is maintained in the runtime and CONTROL SEND can skip the "get the handle" part of the operation.

We can all guess at how DDT statements are implemented, and often guess well, but we don't really know, do we?

My point was more, mixing DDT and SDK like this is not a good example... while there are occasions you can get away with it, mixing/matching will NOT universally "work" and I'd hate for 'newbies' to get the wrong idea.

MCM

[Chris Boss]

Michael,

You are incorrect. By running the Depends utility on the tooltip app I wrote (I added a CONTROL SEND to the code to test this) , no call to SendDlgitemMessage is made by the app. DDT doesn't use it.

This means DDT is likely doing exactly what I said. It is making a call to GetDlgItem and then SendMessage (both of these APIs show up in depends).

I use depends often to test applications to see what API calls they are making and it is useful in testing to see how DDT accomplishes things.

DDT gets a bad rap from SDK style coders as if it is some kind of proprietary engine which does things in an abnormal way. DDT actually is a well written set of wrappers which are quite low level. It utiltizes the Dialog API's in Windows in a very standard way.

DDT simply uses its own internal dialog procedure, instead of the one the programmer defines for the default dialog procedure for all dialogs created. That dialog procedure, then does its thing (meaning it handles a number of mundane tasks) and then forwards messages to the user defined dialog procedure (if they define one).

I have found DDT to be very close to the Windows API so I have had no problem in integrating API calls with DDT calls. As long as one treats DDT as what it is, a wrapper over the windows Dialog API, then one has few problems if any. It is just that one needs to make sure that you don't treat the dialogs as if they were a custom window class, using window procedure techniques, rather than dialog procedure techniques. If it can be done using the windows dialog API's it can be done with DDT.

About the only concerns are making sure you use the DDT commands for things the DDT engine strongly depends upon and also to stay away from things dialogs were not meant for. For example it is good to use a DDT style message loop, since it makes the needed calls for you. MDI is not possible with Dialogs, so it is not practical to use it with DDT. It is not a DDT problem, but is a Dialog problem. I overcame this in my GUI engine, by dropping the dialog class and using a custom dialog class. My custom dialog class, simply acts like three different classes (dialogs, frames and MDI children). DDT uses the dialog class and does not superclass it or something, so it is only limited to what dialogs can do.

DDT is not some kind of "black box" to be afraid of. My feeling is that Powerbasic went to great lengths to do things right in the DDT engine to follow the standard use of the dialog class.

Windows was designed to be customized. Windows cans be subclassed or use other tricks to override how things are done. This is not a black box. It is simply a means of allowing programmers to customize how they do things. DDT simply takes advantage of such features in Windows to simplify the programmers task. It is quite compatible with most of the API.

[Chris Boss]

Just to point out that Microsoft intended the API to be customizable, even when wiritng compilers, take a look at Visual Basic.

Visual Basic 5.0 didn't use the controls classes built into windows directly. It superclassed all the controls so it had access to the window procedure of every control class. This is why the class names started with Thunder (use Borjes WinSpy to test window classes).

Microsoft built there compiler on non-standard window classes, but custom classes they built upon the existing classes. Now that is a black box.

The point is that API allows multiple ways to accomplish things, and DDT simply takes advantage of that. It does far less mysterious things does many other compilers. Just check to see what window class those compilers are using (ie. EBasic or IBasic).

For those who are learning to use DDT, as an experienced API programmer, I would say don't be afraid to use the API with DDT. You will learn a lot if you learn about the Dialog API's in Windows used by DDT. Understanding the Dialog API's DDT is built in, will help you appreciate why DDT works the way it does. It is not some scary black box to be avoided.

[Michael Mattias]

You are incorrect....

By running the Depends utility on the tooltip app I wrote (I added a CONTROL SEND to the code to test this) , no call to SendDlgitemMessage is made by the app. DDT doesn't use it.

No, I am not incorrect. I stated DDT was NOT constrained to use that particular set of API functions to implement CONTROL SEND; and it is not.

It appears from your research PowerBASIC has chosen - in this particular version of the compiler - to use those functions.

DDT is a proprietary technology. It is not a substitute for the WIn API; DDT commands may not be freely interchanged with SDK-style commands. DDT commands are only supported with DDT-Created screens and controls. Windows API commands may be used with DDT commands where indicated in the PB Help.. e.g, it is documented that both DIALOG NEW and CONTROL HANDLE return valid Windows window handles which may be used with API functions requiring a valid window handle.

But my point is still as above: mixing and matching "SDK" with "DDT" is not to be done at will; and providing a good example to newcomers should help make that clear.

MCM

[BOB MECHLER]

Very nice Chris.

Thanks,

Bob Mechler

[Cliff Nichols]

I find it a nice intro to "Newbies" that are wanting to branch out.

Simplicity of DDT, and some API commands and not a leap of confusing faith trying to understand the differences.

Too many differences, or concepts can sway a programmer away from one style or another just because they "Don't totally get it"

In the past, I was working on a lil example to show DDT vs API but got stuck in several spots of "OK now what the HECK did M$ mean by this in the API docs???"

I don't know about others, but I learn by comparing a style that I don't get, to a style I do get, and figure out why/how they are different.

Anyways....NICELY DONE there Chris

(I will have to look closer and tear apart, but could make for a heck of an example of pure DDT vs pure API example)

[Chris Boss]

If DDT is the core method one uses to create dialogs/controls then yes, the API can be mixed with it without many problems.

Of course if you use, SDK style coding as the primary method of creating windows, one has to be careful how you use DDT commands, since it assumes the dialogs are using the DDT engine internally. That is common sense.

My point is that, if DDT is the way one codes, one should feel free to intermix API calls, rather than DDT commands, if one prefers. I do and I don't have a problem when coding using DDT.

[Chris Boss]

Just a point about the term proprietary.

If one wants to be technical, any library of code, whether precompiled or as source code is proprietary (meaning of anothers design). My own GUI engine is technically proprietary (and definitely much more of a black box than DDT is).

Even when using tools like Third Party Designers, which generate 100% code, is using a proprietary tool. Why ?

Because, even with source code, it could take days, weeks, even years to fully understand the code written by someone else.

Who sets the standards of how they should accomplish things ?

One uses the Dialog class.

Another uses custom window classes.

What I am refering to about DDT not being a proprietary black box, is that Powerbasic appears to stick close to the API in their command set and the commands are not far from calling the API directly. Sure they use a few tricks internally, but compared to something like Visual basic (even my GUI engine), it is as close as one could get to the API, with a programming language command set. Compared to say, COM with all its overhead and the OOP stuff (which is usually used for most COM objects like controls), DDT is far closer to the API than others.

If one knows how the Dialog APIs work, then DDT is not foreign at all, but makes a lot of sense. Sure, I may wish some things were done a little differently, but Powerbasic has a goal and it appears to have done well with it.

As far as I am concerned, DDT is not some mysterious black box which can't be understood. There are only so many ways to do certain things in Windows and DDT has only so many APIs to choose from for certain tasks. Knowing PB's tendency to stay low level, I doubt they are doing anything really tricky under the hood of DDT. How many different ways are there to send a message ? CONTROL SEND only has a few options available to accomplish the task. Using the depends utility one can even weed out most of them and take a very educated guess how they accomplish something (at least as far as DDT).

I don't find DDT to be a liability. Sure I may prefer some of my own tools, but since most use DDT, I can live with it and understand it.

For newbies, don't be afraid of the API. They key is to understand what DDT is doing first (in API terms) and then you will be able to integrated API code that works well with DDT code.

[Chris Boss]

Just to make a point:

If any PB coding style could be called a proprietary "black box", it is my own GUI engine. You all know what it is.

It is a complex GUI engine with thousands of lines of code.

Yet, I encourage all my customers to integrate the API when needed freely. Many of my customers write a good bit of API code alone with my GUI engine command sets code. I have yet to find a situation that caused a serious problem with using API code. Sure, once in awhile a user may have to experiment a little to make sure their API code works well with it, but all in all, there are very few problems.

I believe the reason is that internally I stay close to standards in using the API.

Now DDT has far less internal code to deal with and is far closer to the API than my GUI engine does. DDT is a low level wrapper over the Windows Dialog engine (API), so how many strange things could they be doing under the hood ?

If my own black box can have API code freely integrated with it, surely DDT will have few problems doing the same.

[Cliff Nichols]

or even more to the point....

What does API stand for??? "Application Programmers Interface"

aka...it depends on your app and what you want to do.

From what I find, nomatter the language, it all boils down to

• You can intermix or match all you want
• You have to be careful, just WHAT you intermix or match from one style to another (this is where problems occur)
• When problems arise...look at YOUR code, and the original intent of the functions being called (either directly, or the "Engine" behind the scenes interpreting what your wrote on top of it
• Its all binary

I have no problem mixing and matching DDT with API (sometimes its easier to DDT sometimes its easier to API)...it all boils down to... YOUR application, and what YOU are trying to achieve

That said given with the "Knowledge you have at the time that you write it"

"You live, you learn, you code, you learn, you (may not live cause you screwed up) ... you start again...you learn... you code...you.......)