Is there a way to make a TaskDialog always on top (ie, system modal)?
I've checked the TaskDialogConfig structure (http://msdn.microsoft.com/en-us/library/bb787473(VS.85).aspx), but I'm not having any luck.
Anyone know how to do it or if it's possible?
Don't know if this is helpful. But you can make the TaskDialog application modal if you supply a window handle to the hwndParent member of the configuration.
Yes, there is a way. You need to use TaskDialogIndirect function and set up a callback. In the callback you get window handle to the newly created TaskDialog. With that you can call SetWindowPos with necessary parameters.
Related
I'm working in a legacy application using MFC.
We have a mechanism to enable/disable controls depending on some business logic.
This mechanism is implemented in the CView-derived class. The way it works is all the views in the application derived from a common CView-derived class (CBaseView) and on the PreTranslateMessage all controls of the view are enabled/disabled.
This worked fine so far because all controls send at least WM_PAINT message when they need to be painted. So the system worked without the user having to move the mouse or anything. I recently added some drawing features and I had to use WS_EX_COMPOSITE to get ride of some flickering. With this flag activated my CView-derived class is not getting any called to PreTranslateMessage when creating the view....so the controls are not disabled until the user moves the mouse over the control.
I understand there is no way to send WM_PAINT using WS_EX_COMPOSITE but is there other message I can use to get the same behaviour???
Edited:
I am currently using the OnIdle approach but it has a big drawback, the windows doesn't become idle until after drawing all the controls...so when you enter the screen al controls are enabled and inmediately they are disabled...this makes a quite ugly effect!
More solutions???
Thanks in advance...
The logical place to enable/disable controls would be CView::OnUpdate, it is called by the framework after the view's document has been modified and from OnInitialUpdate(); you can also call this function if there is some change that would trigger re-evaluation of your business logic.
EDIT
After reading the question a bit more closely, what you could also do is to post a private message at the end of OnInitialUpdate and "catch" it in your PreTranslateMessage:
PostMessage(WM_APP, 0, 0);
Calling InvalidateRect followed by UpdateWindow against the window in question will mark the entire client area as dirty and force an immediate repaint. Remember that WM_PAINT is not really a message, in the queue in the usual sense, it is pushed out after all other messages have been processed for that window, which would include any invalidations of the area being drawn. No message is generated at all if there are no invalid segments of the active window display.
I need to execute a pascal code before that the Select Setup language Dialog is shown , unfortunately the InitializeSetup event is executed after.
function InitializeSetup(): Boolean; //This event occurs to late
begin
DoSomething();
Result := True;
end;
So it's possible execute a script code before of the Select Setup language Dialog is shown?
I had similar problem, and I thought about different workarounds: style all setup manually, or make inner localization, but they all looked so doomed from the beginning.
Select Setup language Dialog
I have forked issrc, built it locally, and looked at the main.pas of the Setup project. I see the idea behind doing as it is now : people may wanna use {Language} in InitializeSetup, so its called after the AskForLanguage method.
To just check the idea I made small changes to main.pas: call AskForLanguage after CodeRunner inited and InitializeSetup called. I got VCL'ed Select Setup Language dialog, but not all - NON Client Area wasnt VCL'ed:
I've tried to inherit the language form not from the TForm class but from the TSetupForm, or call it in the middle of setup or make other changes - with no result. If anybody know why it's not VCL'ed - tell me please!
Then I read the Custom Window Frame Using DWM article and just made the form border bsNone and got this:
So for now I'm fine with it. That form not styled before many pages of styled setup was so... annoying.
If we wanna do it a right way, I guess all that needs to be done - is moving CodeRunner init before AskForLanguage, and add a custom code function like StyleInit or so. Then all will be happy: {Language} will be available in InitializeSetup and Dialog will be VCL'ed.
No, the function InitializeSetup() is called as first.
All other functions are called later.
Of course you can modify Inno's sources and add custom functions but I think it is not your case.
Why do you need this? Maybe there is solution which can solve your situation, please tell us details.
Another possible solution is using Inno setup Ultra, it has several inprovements, and InitializeLanguageDialog function is one of them. just load style in it. (Also you can freely change language dialog itself that is so nice).
In am using YUI browser history manager for keeping track of Ajax navigations. I am registering history object like:
YAHOO.util.History.register("state",init, onStateChange);
Here onStateChange is getting called when I do
YAHOO.util.History.navigate("state",urlhash);
and when I press back button.
Is there any way to know if onStateChange is called on back button or by calling navigate?
If this event can be called by an external system sometimes (in this case the browser back button) and by your own code sometimes, you can differentiate the caller by making it a requirement to do something special when your own code calls the method. Wrapping the call to navigate() in your own helper method can help make sure you stay consitent with this.
In the YUI docs I see that register() can take an optional 4th parameter (among others) which is an arbitrary object that will get passed into your onStateChange handler function. One of the properties of this object could be a flag indicating that it was called from your code versus initiated by the browser, and in your navigate() wrapper always set that flag. Remember to set it back in your handler.
Note: I am not as familiar with YUI as ExtJS, maybe some guru that knows the API better can help, but this is a general strategy that can work. This answer makes an inelegant assumption that a call to navigate() will make that handler fire reliably before any other navigation has a chance to occur, which is probably a safe bet in the single-threaded javascript world.
In my custom actions, I've used MessageBox.Show() to show a dialog whether needed. For ex: during database installation, I'd like to show a message to user if any error. But the message box is not set as a child of Wix window by default, thus the end-user can leave the message box and touch the Back, Next button ...
Is there any way to set the message box as a child of the main Wix installer window?
Thanks in advance,
There are bad ways and good ways. The bad ways involve FindWindow calls so you can parent appropriately. The good ways involve calls to MsiProcessMessage, Session.Message, or whatever wrapper is available. However if this custom action is being invoked from a DoAction ControlEvent, the latter will not work.
I have a TThread which receives and sends to a device on a COM port. After I read the data, I want to activate the GUI (not in the same thread) using Synchronize(function name). However, when I call the GUI's form function to perform a button click, I get an access violation. I checked to see if the form's value is null and it is not, since this would be an obvious reason for access violation. Right now, I am setting global flags and using a timer that continuously checks to see if a certain condition is met and if so, then I fire off the button click event in that form. That seems to be the only way to avoid getting the access violation.
I really don't like timers so is there a way to avoid having to use a timer on the form?
You can post a message to the window in question. The timer works in a similar manner. It just fires off a windows message inside the form. You obviously have a handle to the window.
CWnd::PostMessage(...) Don't use send message, it gets processed inline and could cause your thread to stop working.
Typically when you have a worker thread that attempts to access Guithread, they conflict. It's been a while since I've used MFC and threading but that's what I remember. I believe it's documented to work that way.
I found the problem. I thought I was checking if my Form was null, but I was not. I fixed it making sure the form I was referencing is not null.
Edit: Turns out that one of the forms that is called when I call Fbutton1Click() is Modal so it blocks my thread. I ended having to go back to a timer to call the button click instead.. oh well.