I want to know how can I simulate the mfc message pump in my dialog based application.
In my application I have one base class as MyDialog. by using this base class I am deriving different kinds of dialogs depending on my requirement. for ex: dialog to get user credentials, dialog to get the folder path for installing program etc. Now the problem is I am trying to show or hide some of the options(controls) on the dialogs on certain conditions. here showwindow() works fine for showing the controls but when I use them to hide the controls It doesn't work at all. But If I minimize or maximize the app ,It works fine. I feel that the window is not getting refreshed (refresh happens when it minimizes or maximizes). why? To make it work I want to create my own message pump. thanx in advance
Related
I am creating a prototype web app using Oracle Weblogic/ADF. I am using JDeveloper 11.1.1.6.0.
I have a basic application with one entity object and one view object. One of the requirements I is that once data is changed it must be digitally signed. I am using a applet/servlet based solution to get this done.
Once a user decides to edit an entry in the table they are taken to a page that shows a two-column form layout. On this page is a button that, when clicked, brings up an ADF dialog window. On this page there is a button called "Sign". Once the user clicks the "Sign" button some JavaScript executes that communicates with the embedded applet. This embedded applet in turn communicates with a servlet and returns a string representing a signature. This process is task-flow based.
The issue I am having is that for SOME users (IE 8, Win 7 Enterprise) once they click the "Sign" button on the popup they are shown the following popup:
If they click "OK", the page reloads and when they click "Sign" again the process repeats resulting in a loop. Initially I thought the alert was coming from IE, but upon further research it seems that the alert is coming from ADF. I have NO idea WHY they are getting this message as there are NO dependent dialogs. I have tried setting the "uncommitted data warning" to off for the document but I still get the same popup. Also the message ONLY appears for SOME users running IE 8 on top of Windows 7.
Does anyone have any ideas as to how to get this popup to stop and/or WHY it is happening?
ANY help would be greatly appreciated as I am stumped.
Thanks.
disable the uncommitted data warning property on af:document
http://docs.oracle.com/cd/E23943_01/apirefs.1111/e12419/tagdoc/af_document.html
Frank
Is it usual to use a Dialog as main Windows? So without registering any user class via RegisterClassEx? Can I do everything I do via CreateWindow()? Why should I create controls such as buttons,editboxes etc via CreateWindow() instead of just making a Dialog and use it as main Window?
I'd also like to know main difference between a dialog and a windows and why use one the first instead of the second.
Thanks
Is it usual to use a Dialog as main Windows?
Yes, it is quite common.
So without registering any user class via RegisterClassEx?
A dialog is usually a predefined window class, so there usually no need for registering.
I'd also like to know main difference between a dialog and a windows and why use one the first instead of the second.
Well, two big differences would be that you cannot resize a dialog box and it has no minimize or maximize buttons (by default, but there are workarounds for this). Keep in mind the name, dialog box. In other words they are used for having a dialog with the user (receive input and displays messages to user). In a sense they are just like any other window, underneath CreateWindowxx, etc. is called, etc. However, they are somewhat predefined windows which can be made quickly and there are limitations to what you can do with them.
Also, a dialog uses a dialog procedure rather than a window procedure, which does some default processing for you, such as initializing some controls, etc.
Yes, an application can be dialog-based. There's even a Wizard for that if your'e using VisualStudio and MFC.
In VS2010, Create New Project > MFC Application. In "Application Type" select Dialog Based. Click through the rest of the Wizard, and you're off to the races.
Dialog-based applications are much simpler, architectually, than other designs such as Document/View. As such, simple things are much easier to "bang out" quickly, but the limitations of the design become apparent when you try to do more complex things. You could end up replicating much of the Doc/View architecture in your dialog-based app in order to build a production-quality Dialog-based application. In that case, did you really save yourself anything?
A dialog is a kind of window just as all of the various controls like buttons are really just windows. You can think of a dialog as being a kind of window with a lot of extra functionality to support the kinds of things that dialogs are used for.
There are two types of dialogs, modal which display and expect you to use them and then dismiss them, and non-modal which display but which do not capture and keep the input focus until they are dismissed. You can see these two types used in applications where a modal dialog is used to display an error or require the user to make some setting and a non-modal acts as a kind of tool box that stays displayed and when you need it, you click on it to do something and other times you are using some other window in the application.
Normally a dialog would not have a menu bar but would instead have all of its controls visible or easily accessible via tabs or some other type of presentation. Visual Studio and other IDEs have dialog designers to allow the placement of various controls along with wizards to allow the controls to be tied to classes and class members.
Which brings up a major difference between a dialog and a window. A window is kind of an empty page and to do things with the page requires more work. A dialog has tools that make the design easy however you are also constrained in large part by the toolbox.
If you have an application that is focused on basically allowing a user to specify certain settings and then do some task, a dialog works fairly well. If you have something that requires more complicated user interaction, an application window as the base from which all of your other dialogs and controls will be managed and manipulated will be more necessary.
I have a small utility app written in Visual Basic 6 that has been happily running on XP clients for many years until recently a client who is using Windows 7 has notified and shown me that the behaviour is different.
When my VB app displays the dialog, it remains hidden until the user clicks on it in the taskbar.
I changed the code so rather than using a ".show vbModal" command, I changed to displaying the form with non-modally, and then added various API calls like BringWindowToFront and SetWindowPos to make it top most AND calling .focus on the form, despite these extra instructions the best result I can achieve is to make the form flash prompting the user to click on it.
No matter what I've tried I cannot make the window display topmost, and with focus, without user intervention.
Note. this is an ActiveX exe project and is being called by a Win16 app through COM.
Has anyone else encountered this behaviour and know of a solution?
Any suggestions/advice appreciated, thanks.
Applications can't (without lying to Windows) steal focus. The calling app should really call AllowSetForegroundWindow() (if it's available on win16) to allow the COM process to steal the focus, or call SetForegroundWindow() itself.
See the help for SetForegroundWindow() for the conditions on setting focus.
I have a friend who's working at a company that offers pretty poor support for its developers (scoring a 1/12 on the Joel Test).
Their build process is locked down pretty tight, and depending on the size of project it could take 40+(x2) mouse clicks to deploy. So I thought, "Hey, why not automate it the clicks using the win32api?" (Specifically using Python). I've got him a real nice tool that works just fine except for one issue - the tool that they use has a navigation pane that may or may not be open.
You can open and close it with a button press, but I'm not sure how I could make sure it was either open or closed. It's irrelevant to the build process - the only problem is that it alters where the mouse needs to click on the screen depending on its open status. The application is written in .NET and it exposes a function call that applications are able to use to toggle the panel, so I've been looking around for ideas and so far I've got two of them:
Attach to the process via a debugger and execute the function call somehow.
Take a screenshot at the location of the panels titlebar (which I've got through the win32 API and doesn't appear to change regardless if the panel is hidden or not).
Is there an easier way to figure out the state of this panel? The developers are given an admin account on their machine in addition to their regular account, so I can entertain ideas that require admin access, though I don't think that should be necessary?
UPDATE:
It looks like there's a button that can close the pane. In UIAVerify something shows up as "text" "Navigation" "btnClose". It says its AutomationId is btnClose but it's a ControlType.Text
What technology is this panel built from? Is it standard GDI or WPF? If its GDI, it should have a HWND. You should be able to find this HWND through either a class name or window title. Once you have the HWND, you can get its width.
If its built with WPF, er, I have no idea, but Snoop does this kind of thing, so I know its possible.
How do i make the common File dialogs App modal using Common File Dialog API ? The dialogs come up modal with respect to the owner window. I want to block all the process' windows when a file dialog is up. In my current code, I am disabling all windows belonging to the app except the dialog parent and when the dialog is closed I enable them again. There should be a better/easy way of achieving application wide modality with Common File Dialogs. Please let me know if there is a standard solution for this.
Manually disabling and re-enabling is the only way I know of in Windows.
The traditional model for Windows applications is to have a single top-level window per instance. (Remember MDI apps?) Of course, there are exceptions, and many apps have always had floating tool palette windows. Nevertheless, the disable-the-parent model works for the lion's share of applications, and it's possible for many-window apps to do what you're doing with manually disabling the extra windows. Thus there isn't much demand for a more general solution.
If you wanted to re-architect things, you could have a master window that owns all the other top-level windows, and make the modal window use the master as a parent, but then you'd have to solve other problems related to the task bar, z-order, and positioning of the modal window.