I am trying closed property sheet dialog directly in my code which created using OleCreatePropertyFrame API. for closing the dialog box I am using PropSheet_PressButton API but i don't know the how to get handle for property sheet dialog.please if anyone know about this suggest me.
It does not really make sense to close a modal dialog if you don't control any of the code inside it.
You control the owner handle so that might be your best option; look for a enabled and visible window owned by your window. Perhaps GetWindow(yourWindow, GW_ENABLEDPOPUP) or GetLastActivePopup. This is slightly hacky of course but what you are doing is not normal.
Related
I'm trying to create dialogs that 'lock' the parent window, but without touching the gtk_window_set_transient_for function.
I notice that Glade allows me to set Transient For and Attach To values, but if I connect those with my parent window (defined in the same glade file) and run the program, it is not transient.
Do I need to do anything else? Does this way even work?
So it does work. I didn't fully realize however that the a locking dialog also needs to be set to be modal.
So to solve my issue I had to also tick the Modal property.
Furthermore, it's also important that both the dialog and the window are loaded from the same builder instance.
Problem: Need to read/capture the text of Windows pop-up messages that is generated by non-VB applications.
Situation:
I've a VB6 app, part of which requires processing an excel workbook. A non vb-6 pop-up window (as attached screen) "FILE CONVERSION IN PROGRESS" comes up, while opening an new version of excel-sheet from an old MS Excel app. And automatically it closes alos.
Requirement: I want to capture that pop-up occurance in the code. And then write a conditional statement code for the 'cancel' button click event of that non vb-6 pop-up.
Can anyone suggest something?
You can access other applications with the following APIs:
FindWindow() to locate the main window of what you're looking for
http://msdn.microsoft.com/en-us/library/windows/desktop/ms633499%28v=vs.85%29.aspx
GetWindow() to navigate through the HWNDs of the application so you can get to the button
http://msdn.microsoft.com/en-us/library/windows/desktop/ms633515%28v=vs.85%29.aspx
GetWindowText() to access the text from a control (it cannot be an Edit control)
http://msdn.microsoft.com/en-us/library/windows/desktop/ms633520%28v=vs.85%29.aspx
You'll want to use Spy++ (which can be downloaded) to see what the class name you're looking for when it comes up and to figure out the hierarchy to navigate properly.
You'll need to use the API Text Viewer to get the API declarations so you can use them in VB6 properly.
Hello I have some knowledge about VB Script, but i need some help so that it will help me to move further and study in VB Script.
I want to make dialog box which will contain :
Two radio button
one Text field to enter some value
OK and CANCEL button
so, could you please help me out?
VBScript doesn't support custom dialogs. You can either use the Internet Explorer COM object to emulate a dialog, or create an HTA. Either way you're building a web page with a form.
We're using the file picker dialog to allow users to add documents into our application. The word 'Open' doesn't make a lot of sense in this case.
Thanks.
I would browse the code found here, which shows how someone extended the OpenFileDialog. Admittedly, this is overkill for you. But I think there is code within to change the button label.
Not really no.
Given the standardization of this dialog it's extremely likely that your users will have used it many times in the past to "add" files to applications. The chances are they will be quite familiar with the implications of the word, changing it may be more confusing to them.
The standardness of the dialog is why it's called a "Common File Dialog". If you want to change it for your app, you'll have to write your own dialog.
Having said that, there are apps out there that can pull a form out of a DLL, modify it, and stick it back in. However, this is a per-machine hack and downright bad form.
Modal dialogs are evil, but I keep reading "You should remove modal dialogs when possible"
When isn't it possible to remove modal dialogs? I mean, what are some truly modal tasks that force us to use evil modal dialogs?
The most common given example is the "Do you want to Save?" I think this is the problem of the concept of having the user hit Save instead of remembering that user input is sacred. If you just saved automatically with the ability to "undo" or have revisions, then you don't ever need ask the user if they want to save.
"Are you sure you want to delete?" Undelete
"Are you sure you want to quit?" Why would you ask that? Are you that vain?
Why do we ever need modal dialogs?
EDIT
Webs app don't count in my books, unless they write their own UI windowing system within the browser. Web apps don't have the same tools set as desktop apps.
EDIT 2
My question is slightly different than the one labeled as duplicate. I feel that there is no case that modal dialogs are the best solution. The referred question assumes there is such a case.
Duplicate of: When Is Modal UI acceptable?
Use Cases for Modal Dialogs
blocking the application flow until information required to continue is entered, as for example a password in a login process.
collecting application configuration options in a centralized dialog. In such cases, typically the changes are applied upon closing the dialog, and access to the application is disabled while the edits are being made.
warning that the effects of the current action are not reversible. This is a frequent interaction pattern for modal dialogs, but it is also criticised by usability experts as being ineffective for its intended use (protection against errors in destructive actions) and for which better alternatives exist.
(Source: Wikipedia)
When I use them
In instances where stopping them from doing something stupid is absolutely mandatory. My company has a web app where Users sometimes leave the page before finishing their work. We prompt them with a Modal (the standard onbeforeunload JavaScript function) if they haven't saved their work.
Otherwise, I don't use Modals if I can help it, I hate it when an app steals focus from what I'm doing.
Edit: We don't save their work automatically for them when they leave the page. We do at other times, but not when they leave the page, hence the Modal. I did write could that could go in and save their work when they left the page, but it wouldn't be a 'great' idea to implement it, especially if they accidentally deleted their work and didn't want it to automatically save.
The only thing more sacred than user input is any file I known about. You should never modify any file that an implementation detail unless I have told you to. Thus boxes like "do you want to save?" at exit are a must because I may want to not save.
Imagine an application which needs to open a dialog for some actions. Now imagine that these would be non-modal dialogs: while one dialog is open, you could change the selection or even worse - invoke a different command which itself opens another dialog. Now imagine the these dialogs would be modal: then you would have to close the dialog to proceed - you can't get in the state where the selection changes under a dialog or where two commands are waiting for input.