I'm forking a existing Delphi 7 application to a new name. I used "Save Project as" to create the new project. I also changed the COM automation typelib library and interface names and GUIDs. All this worked fine.
But after I changed the Application.Title (>Project>Options>Application Settings>Title) the application is showing a strange behavior: It runs normally, but the wait cursor keeps rolling after the application starts. Every thing else seems to work fine.
If I change the title to any other name, the problem goes away. Even adding an space in the end of the name solves the problem. The name is 6 characters long, all letters. No symbols, spaces or numbers. I'm puzzled.
What is the Application.Title used for, besides showing in the Windows footer and task manager ?
Application title used solely to display the title for the application in the windows taskbar. By default it has same text as the name of EXE file. You can change it dynamically like this
Application.Title := 'two';
I confirmed it with the book "Delphi-7 second edition" writen by Homonenko Anatoly Dmitrievich. Even though it was written in Russian.
PS If you give me the word you used, I check it on my installation of Delphi-7 on Win-7x64
Related
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
I'm running into a very strange problem with the Vcl.FileCtrl function SelectDirectory (which is a thin wrapper around the ShBrowseForFolder Win32 API).
I'm using the following code to allow the user to browse for a file or a folder:
if SelectDirectory('Sélectionnez un élément à ajouter :', '', S, [sdNewFolder,
sdShowFiles, sdNewUI]) then
When executing this code, the "Browse for folder" dialog is correctly shown, displaying the content of the user's Desktop:
But when the number of items in the Desktop folder is excessively large (on my computer, I can reproduce the problem by having approx. 100 desktop icons), the same call produces a totally different display:
In this case, the Desktop items aren't shown anymore. I'm only allowed to explore my home folder and since I've lost the "My Computer" icon I cannot select a file/folder outside of this directory.
I'm searching what I'm missing here. Is there a limit in the number of subitems a root item can have for a correct display? Having a lot of desktop icons is certainely not a good practice, but as far as I know that shouldn't prevent this dialog to operate normally. I'm not sure if there is something wrong in the Delphi wrapper, or if that's a limitation of the API I didn't see on MSDN...
Any hint appreciated!
Yes, I can reproduce this behaviour. It's clearly a Windows limitation and the API in question does not offer you any way to increase buffers. I think your chances of working around it using SHBrowseForFolder are close to zero. Because SHBrowseForFolder is now a a legacy API.
If you are browsing for folders then you should use IFileOpenDialog in folder selection mode. That's a a much nicer dialog that uses the new Vista dialogs. In Delphi that is wrapped by TFileOpenDialog. Only use that if Win32MajorVersion>=6 though! For XP you need to call back on SHBrowseForFolder.
if Win32MajorVersion>=6 then
begin
FileOpenDialog1.Title := 'Sélectionnez un élément à ajouter :';
FileOpenDialog1.Options := FileOpenDialog1.Options + [fdoPickFolders];
if FileOpenDialog1.Execute then
Beep;
end else
begin
// revert to SelectDirectory
end;
The workaround I came to is to use the "old" (Win XP) UI, which can be done by not specifying the [sdNewUI] flag. In this case, all the items are correctly displayed.
That seems to be the only valid solution when the user must select files OR folders, something TFileOpenDialog is not capable of.
I have an application in which view and edit of a script(which is a .txt file) has to be performed. I am using a RichTextBox on .net platform for this. When user wants to view a script, I just copy the script in my richtext box with WordWrap true. But when user has to edit it, I have to show it in a single line. This does not require the word wrap property to be true.
But this is working fine on WindowsXP but when viewed on Windows 7 PC, on editing, the script is truncated. If user clicks anywhere on the dialog box which has richtextbox, the whole script can be seen. This happens each time when user selects to Edit it.
Also, If I do a remote desktop to Windows7 PC, the script can be seen properly at once only when editscript is done.
Can someone please help in this?
Can this be graphic card issue? I have checked changing the resolution but it didn't work
We are using Delphi 7 enterprise edition, application is build on windows XP, testing on both Windows XP and Windows 7.
In an application we maintain, something strange is happening. For some reason hitting the "-" key (qwerty layout, between "0" and "=" keys on top) does not register at all.
We checked in the OnKeyDown of the edit we found it with, the OnKeyDown of the form (with and without key preview) and even the ProcessMessage routine, but the event for this key never reaches the application.
We get the same results for OnKeyPress.
Yes, the "-" key on the numpad DOES work. Also, this behavior is only seen in this application, but if we create a new application with only the OnKeyDown of the default form in unit1.pas implemented. it does work.
So somehow we managed to tell the application to properly ignore this one key.
Does anyone have an idea how this could be (un)done?
David's comment is on the right track; You can (with version control) strip back the app until you understand what is going on. However I think that you need to understand the following concepts as well:
OnKeyDown event in a form is not the only place that keyboard shortcuts could go. You should find out where else it's going to, which is why Sertac's comment is there.
It is possible that something OUTSIDE your application is trapping that keyboard key (although this is more common with Control or Alt + Key combinations).
It is possible that something inside your form, or elsewhere in your application is grabbing that key and consuming it.
There is a good article here about KeyPreview, you need to understand that too.
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.