I'm using Delphi XE3 in a complex application that has MDI forms, and forms that stays on top also.
Sometimes a simple ShowMessage('...') does not appear and stays behind the main application window.
Either people think that the application has crashed, or go to task manager and put back the application on top, and then showmessage windows come back on top.
This is occuring in XP, I haven't seen that under Win8 so far.
Any idea why?
You can try this:
Wrote your own myShowMSG function. In this function wrote the simple custom message form and some code to control - "Are this form are visible to user?" In control code write to error.log all tracelog information about this problem. Include the list of actually created forms and their states to .log
Replace all ShowMessage in your project to myShowMSG
Run all tests
Read your error.log's. Post it here to disquss
Related
I am working on a project but I faced a problem in making a form stay always on top like task manager in delphi
I used this code but didn't work
SetWindowPos(Form1.Handle, HWND_TOPMOST, 0,0,0,0, SWP_NOACTIVATE+SWP_NOMOVE+SWP_NOSIZE);
Modern task manager uses internal private Windows functionality for its stay on top behaviour. The system does not make this available to user windows. The functionality that task manager uses simply isn't available to you.
Related question: Is Task Manager a special kind of 'Always on Top' window for windows 10?
Just use the Object Inspector at design time to set the form's FormStyle property to fsStayOnTop.
The code from the original post might work on a main form, but will not work on a secondary form. fsStayOnTop is only part of the solution for a secondary form. Below is an easy solution for making a secondary form stay on top while the main form is obscured by other applications - without resorting to showmodal or form creation hacks.
Put this in the "Form B" OnCreate event:
FormStyle:= fsStayOnTop;
but that alone won't do the trick...
Drag a TApplicationEvents onto your "Form B"
In the OnDeactivate event for ApplicationEvents1, add the following:
SetForegroundWindow(Handle);
I keep an eye on a small status window while my main form is crunching data out of site. Works beautifully!
We have a complex Delphi application with a main exe and several dlls.
In main form (contained in application exe) we have menubar.
On selecting a menu the corresponding dll is loaded and a form conatained in the dll is shown modal.
The scenario is as follows:
Press F1 and the context help for the modal form is open.
Close the modal form (without closing the context help).
in the source code we have:
result := FreeLibrary(MH);
And the whole application crashes with the following windows error:
ERROR_ALLOCATE_BUCKET
602 (0x25A)
The bucket array must be grown. Retry transaction after doing so.
If we first close the context help and then close the modal form everything is ok.
The strangest thing is that we have 3 dlls crashing and 3 not crashing.
The flow goes thru the same code.
There is nothing in the Windows Event Log.
I thought as a workaround I could force close the context help on closing the modal form before unloading the dll but I cannot find pid or some task identifier which I could kill.
There is no child processes of the application pid.
In Task Manager 'Processes' tab I see the name of our application and the name of chm-file (without .chm) like a subtask (at least seems like so) and I can right-click 'Stop task' but programatically I cannot find this...
P.S:
We use .chm file and do not have HtmlHelpViewer in uses of any module.
We have associated specific help topic to controls in forms so they automatically display the corresponding help topic when the user focuses it and presses F1. So in fact we do not use Application.HelpCommand(.....) to show the help
**** edited ****
Currently we use Delphi Tokyo. The product is stared 15 years ago in Delphi7. It has several dll-s (some of them are extra product modules) with plenty of forms and frames.
**** edited ****
**LU RD's answer solved my problem:**
Application.HelpCommand(HELP_QUIT, 0);
P.S:
I cannot mark the answer as accepted. I do not know why.
"I thought as a workaround I could force close the context help on closing the modal form before unloading the dll but I cannot find pid or some task identifier which I could kill. There is no child processes of the application pid".
In order to close the context help, add this line in the modal form OnClose() event:
Application.HelpCommand(HELP_QUIT, 0);
Application.HelpCommand: Provides access to any of the Help commands in the application programming interface (API) of native Help handling functions HTMLHelp, WinHelp, or other.
See Vcl.Forms.TApplication.HelpCommand for further details.
I have a Windows console app created with Embarcadero XE 6 (in fact converted from a Borland C++Builder5 project). It has a single form with a few buttons and edit controls. All these controls have set TabStop=True and appropriate TabOrder's. However, pressing Tab in runtime when the form is shown does not do anything (it just produces a sound when a cursor/focus is in an Edit control and does nothing when a button is focused).
I have read in docs that Tab order would not work unless the Parent of the form is set. However, this is the only VCL form (the other windows are the console and the GLUT window), so there is no VCL parent AFAIK. I tried to set
Parent=Application->MainForm;
in the Form's constructor, but the Application->MainForm is also NULL. Any ideas?
Your problem is that you don't have a message loop. This is because console applications are not expected to have windows and do not come with message loops by default.
You can run a message loop by calling:
Application->Run();
However this will probably stop the console part of your application from working properly. How can your main thread service the console synchronously and the asynchronous GUI message loop at the same time?
I suspect you will need to have a more serious re-think of your application design.
Regarding your update, it seems that you do have a message loop, but it is the message loop for the GLUT framework. The VCL framework requires its message loop to handle dialog messages like TAB key presses.
It's plausible that running the VCL message loop in place of the GLUT message loop would give better results. But it's quite likely that would just break the GLUT part of the app.
Trying to run two incompatible GUI frameworks out of a single message loop is hard to get right. There's probably no quick fix here. You'll need to dig deeper. Perhaps it would be best to give up on the VCL and stick to the one GUI framework.
Earlier today I went to open a file in a Delphi app I wrote. For some reason the connection to the file's network was down--reasons unimportant--and Windows created a dialog box alerting me to the problem. My app's main form, however, was on top of the newly created dialog (i.e., there was a form for my app, for the File Open dialog, and for the warning dialog box). The warning dialog was modal, and hidden behind the main form. Obviously, I had a problem.
Any idea what's going on, or how I can remedy the issue? The main form's position property is set to poDesigned, and I save/load the form's position on close/startup, I'm too much of a newbie to even know what info would help you diagnose the problem. To be clear, though, the issue was not the File Open dialog--that was displayed where it was supposed to be displayed--the issue was the warning dialog.
Thanks, as always --
I don't understand why is Windows creating a dialog in your app. Which API call resulted in that happening? Normal file operations don't show UI.
Most likely you were using an API function that can show UI, perhaps from the shell API. Any function that can show a modal dialog will request an owner HWND.
For example consider MessageBox(), a function that you know will show a modal dialog in your app. Its first parameter is called hWnd and is documented
A handle to the owner window of the
message box to be created. If this
parameter is NULL, the message box has
no owner window.
Raymond Chen has a whole series of articles on modality which explain why setting this is important.
I have a hunch that you are calling some Win32 API function that shows modal UI, and are not setting the owner HWND correctly. Of course, I could be completely wrong, but there's not more information to go on.
You can stop this by using SetErrorMode before trying to open the file on the network share:
var
OldErrorMode: Integer;
begin
OldErrorMode := SetErrorMode(SEM_NOOPENFILEERRORBOX);
try
if OpenDialog1.Execute then
begin
// ....
end;
finally
SetErrorMode(OldErrorMode);
end;
end;
Later versions of Delphi (IIRC, D2007 and higher) added an overloaded version of TOpenDialog.Execute that accepts a window handle as a parameter; this sets the TOpenDialog's parent and prevents the OpenDialog (and any error window it generates) from appearing behind the main window.
NOTE: You can get to the background dialog (from Windows) using Alt+Tab to cycle through until your application comes back up; this usually brings the hidden dialog forwaard on top of your form.
I put a TLinkLabel on my form, filled it in with a caption including a valid HTML link, and got some nice blue underlined text. When I ran the program, I expected it to invoke Firefox (my default browser) and open the link automatically. Apparently that's not the case.
The helpfile says I have to code this in an OnLinkClick event handler. It doesn't say anything about how to do that, though. It'll pass in a string value called "Link". How do I say "invoke the default browser and have it open Link"?
You can call ShellExecute.
I wrote this method for generic calls, and should works in your case.
procedure ShellOpen(const Url: string; const Params: string = '');
begin
ShellAPI.ShellExecute(0, 'Open', PChar(Url), PChar(Params), nil, SW_SHOWNORMAL);
end;
In your code you should call this
procedure TForm1.LinkLabelClick(Sender: TObject);
begin
ShellOpen(LinkLabel.Caption);
end;
I have all sorts of problems with TLinkLabel that ships with delphi 2010.
a) The control does not render as a hyperlink but as a simple label text on the form. b) the cursor does not change to point out this is a link even though I set the Cursor property. c) the OnLinkClick event does not fire at all.
I am working on windows 7.
So, as far as I am concerned, TLinkLabel does nothing as it should and is useless. ShellExecute is the only solution and must be placed in the OnClick event.
TLinkLabel provides a label that looks like a link. It's your job as the programmer to make it act like a link because only you can know what links are supposed to act like in your program. You wanted the label to automatically open the user's default Web browser using the URL in the label, but that's not the only thing links do. For example:
Internet Explorer is not my default browser, but when I click a link in Internet Explorer, I do not expect the linked page to open in Firefox.
When I click a link in the help program, I expect the linked topic to appear in the help program, not in any Web browser at all.
The preference pages in Eclipse are very complicated. Settings on one page are sometimes related to settings on another page. There are links on those pages that take the user directly to the related page. There is no URL and no HTML involved in this case, and yet they're still labels with underlined text.
Some programs try to offer a choice between opening links in new windows versus re-using old windows. You can't implement that feature without knowing which browser is in use. Your program might offer the user a choice to ignore the default browser setting and always use a specific one. To do that, your UI control can't make too many assumptions about what the program is supposed to do.
I'm guessing you're referring to a TLinkLabel control that comes with Delphi. (My versions don't have such a component.) I imagine that the Delphi control is meant to mimic the one in the .Net class library. It can hold multiple links, and each link can do something different.
If you want a control that always does the shell's default action for URLs, then consider using a different TLinkLabel; the one by Alexander Bach does exactly what you expected. It's from Delphi 3, but it should work unmodified in all later versions as well, including Delphi 2009. If you look at the code, you'll see how it works. It simply calls ShellExecute, as Cesar's answer demonstrates.
LOL, it's funny. So instead of setting crHandPoint as cursor, colored and underlined font and filling the OnClick event to standard TLabel we have component that knows link tag and which at all I need to supply with same On(Link)Click event :))
Only thing it is good for is that it makes easier to embed link into some text and that it is using system style of link...
p.s.: really you have to put Some text with link into the Caption and setup OnLinkClick to that ShellExecute...
I use a control called TInternetLabel instead. It does exactly what you want: on click it opens the browser so you don't have to put code in the OnClick event.
I tried this solution but it still gave problems in Delphi XE4, probably becasue ShellOpen does not understand the HTML-code in the Caption.
What worked for me was a combination of Cesar Romero (the basic code), Adam Feistner (The HTML-code in the Caption) and an older solution:
Put the URL in the HINT field.
Change the line: ShellOpen(LinkLabel.Caption);
to
ShellOpen(LinkLabel.Hint);
This worked for me.