Win7/x64, Delphi 6 Prof.
Win7 drives me crazy with his side effect. I describe it:
When I force the suggestion with Ctrl+Space, or Delphi do this automatically, the Delphi don't show the suggestion dropdown listbox, he is only bring my all opened forms to front, one by one.
This causes that what I typing is not going to editor window: it is going to any property of the active form, of the active control.
For example.
Ctrl+Space+"ShowMes..."
I don't got ShowMessage with suggestion listbox, I type ShowMess into my main form's caption.
Many times I need to make update pack's because the buttons, caption, etc got "ShowMes" or "Excep" or other property, because I type into these windows...
This function is sometimes broken on win7.
May I can restore the normal working mode without "bring all opened form to front"?
Thanks:
dd
You can disable UAC in Windows 7, see here:
http://www.petri.co.il/disable-uac-in-windows-7.htm
Also running Delphi 6 in Windows XP compatibility mode should do the trick.
See this discussion on the embarcadero forums, it's about Delphi 7, but it's the same issue:
https://forums.codegear.com/thread.jspa?messageID=204928&tstart=0
Finally see here how to run a program in XP compatibility mode:
See: http://www.w7forums.com/application-compatibility-mode-t314.html
Or: http://www.sevenforums.com/tutorials/316-compatibility-mode.html
Related
I use Delphi XE2 on Windows 8. I have ported an D2009 application to XE2 and suddenly the save dialog (TSaveDialog) is very slow.
When Project/Options/Application/Runtime Themes is set to Enable Runtime Themes:
=>
When I open the save dialog the window freezes for about a minute (sometimes I can close the window but have to wait about a minute until I can open the dialog again (or another TOpenDialog). The new Vista style save dialog is shown.
If I try to run this exe on a PC with Windows 7, the app hangs upon start (I did also try with XP compatibility mode without success).
When Project/Options/Application/Runtime Themes set to none:
=>
Save dialog works well (fast) but the old style dialog is shown, se example below:
This exe works well on a PC with Windows 7 (though with the old style dialog).
Ps. My old exe-file compiled with D2009 on a Win 7 PC works however well on both the Win 7 and 8 PC:s, and shows the dialogs correctly using the new Vista dialog style.
Could it be some permission rights in Win 8/7 causing this? I use IDE FIX PACK 5.4,
Thanks,
Thomas
I found what the problem is. I use {$MAXSTACKSIZE $4000000} and this causes the save dialogue to freeze for about a minute.
The reason for this hefty stack size is that I use a recursive algorithm (that I now probably need to remake).
Reproduce as follows (XE2):
Create a new VCL forms application
Place a TSaveDialog1 on the form
Place a Tbutton with OnClick event
`
Begin
if SaveDialog1.Execute then
MessageDlg('ok', mtInformation,[mbOk], 0);
end;
`
4: Open the project source file and put the following rows:
//{$MAXSTACKSIZE $3500000} //this is a decimal value of 5 5574 528 OK!
{$MAXSTACKSIZE $4000000} //this is a decimal value of 6 7108 864 Not OK!
Run and click the button. Give a dummy file name and press save. Nothing happens. Keep on clicking the button for 60 seconds. The dialogue will finally close.
Change to the smaller stack size $3500000. Now the program works well. Thanks for all tips.
I guess this is yet another reason why VCL styles are not ready to be really used.
TDateTimePicker control looks fine without VCL styles. Turn on any vcl style, and I get this appearance:
I can turn off the vcl styles for just this component type, by registering a style hook, but that looks really ugly.
This is on Delphi XE2 with update 4 installed.
Ideally, I hope there is a workaround, or some properties of the datetime picker, or some subclass of datetimepicker I could do to force the datetime picker to paint and theme correctly.
Note that normal comboboxes are theming correctly. Note that this reproduces easily in the most minimal sample project imaginable. Yes. It's Yet Another Styles bug.
Update It might be platform specific, related to Windows Common Controls versions on Windows Server 2008 R2 without Aero ("Desktop Experience" in Windows server component terms). It just occurred to me after other people cannot reproduce it, to try this on several different Windows machines. After I did that, I find that the problem only reproduces on Windows Server 2008 R2. Some of our customers use Windows Server 2008 R2. As you know a major reason for using VCL Styles is that it makes your app look the same regardless of what the windows theme is. However in the case above, the whole app themes properly, except the DateTimePicker control, which is themed incorrectly, and only on Windows Server 2008 R2. The same XE2-based demo app works fine on Windows 7.
Both the working and non-working systems have a ComCtl32.dll in the SysWow64 folder with version reading 5.82.7601.17514. However, clearly the native layout and appearance of these controls is different, when VCL themes are off, and this affects the skinning code, which fails.
Update2: Reported as a bug: QC Entry 106783
Ok, I just made a small change to the Vcl.Styles.DateTimePickers unit which is part of the vcl-styles-utils. To fix this issue when the "Windows Classic" theme is active.
Use this style hook in this way
uses
Vcl.Styles,
Vcl.Themes,
Vcl.Styles.DateTimePickers;
initialization
TStyleManager.Engine.RegisterStyleHook(TDateTimePicker, TDateTimePickerStyleHookFix);
And this will be the result.
I can confirm that when I install Desktop Experience, enable Themes and start the Themes service, this glitch goes away.
Okay here's my workaround code for now:
function DetectWin7Or2008R2ClassicTheme:Boolean;
begin
if ( Win32MajorVersion>=6 ) then
result := (not Themes.ThemeServices.ThemesEnabled) // and IsServerOs
else
result := false;
end;
// main form initialization section:
initialization
if DetectWin7Or2008R2ClassicTheme then
TStyleManager.Engine.RegisterStyleHook(TDateTimePicker, TStyleHook); {no theme!}
end.
It's clearly a wild corner-case. I expect to find more, and I'll come back and update this question when I find what else breaks on Windows Server 2008R2 or Windows 7, when the theme service is not running, which is what happens when you pick "Windows Classic Theme" on Win7, also.
I am running Delphi 2010 on both a 64 bit windows machine (Win 7), and a 32 bit windows machine (XP).
I am trying to learn how to use the TRibbon control.
I have been following the example in Marco Cantu's 2009 Handbook and watching YouTube Demos, but my control is not working like that as explained in the book or demos.
I added two tabs, by right clicking the control. However, the TRibbon looked as exactly as it does in my screenshot, when i drop it on the main form. It is not as high as the ones in the books or youtube demos.
I have tried the same thing on my Win 32 laptop running Windows Xp and Delphi 2010 and get the exact same results
here is what it looks like on my machine
here is what it is suppose to look like in a demo
Once again. When it drop it on the form, it does not take the shape and height as that as i see in the demos. Even when i add tabs. Did i do something wrong during my Delphi 2010 installation?
I managed finally to reproduce the problem in Delphi XE (Update 1) on Win7 64 with Aero enabled. It seems that the size gets set wrong in the .DFM file, and because the Ribbon doesn't support manual resizing you can't visually fix it in the IDE (although it appears correctly at runtime) or in the Object Inspector. It occasionally appears correctly at runtime, but it seems that's sporadic as well.
It's a nasty bug, because it makes it impossible to design the Ribbon. You can add RibbonGroup items, and assign the ActionManager, and try and design it completely using the Structure Pane, but of course that's not a practical solution.
Fortunately, there's a pretty easy workaround, although it's annoying to have to do. :)
I managed twice to get the following workaround to function, but starting over it failed to work several times, so it's a possible way around it (no promises - worked in XE, consistently failed in XE2 Update 2):
Right-click on the Ribbon and add at least one tab.
Right click on the form in the IDE, and choose View as Text from the context (pop-up) menu.
Find the Ribbon control in the .dfm text, and change the Height from the 26 that the IDE assigned to 200. (The next step will adjust it, but that's fine - the 200 fixes the immediate problem.)
Right-click again, and choose View as Form, and the Ribbon should display correctly.
(I reported it in QC against XE2 Update 2, as the problem also exists there - QC #101642)
I traced it to TCustomRibbon.GetCaptionHeight, specifically
FCaptionHeight := Max(GetSystemMetrics(SM_CYCAPTION), 26);
It seems like the GetSystemMetrics call is returning something less than 26 on certain Win7 configurations (although I can't figure out why yet). There are a couple of commented lines in that method that seem to alter the result, but as I said they've been commented out.
The strange part is that in the TCustomRibbon.Create, the Height is set by a call to GetRibbonMetric(rmFullHeight), which sets the Result := cRibbonHeight + GetCaptionHeight;, and cRibbonHeight is a constant defined as cRibbonHeight = 117;.
Finally think I've tracked this down. In the declaration of TRibbon, there's a published property declaration:
published
...
property Height default TCustomRibbon.cRibbonHeight;
Because this is the default, it appears that any other value means that the call to GetRibbonMetric mentioned above doesn't happen (see the TCustomRibbon.Create mentioned above), and the strange result from the call to GetSystemMetric causes the erroneous value 26 to be saved as the 'other value`. Wierd; will update the QC in the AM.
Addendum: Updated QC report with additional details.
Addendum: QC report opened in May 2012, but does not appear to have been resolved as of XE5 Update 1 (checked Jan 2014).
Has someone else experienced something like this with Delphi and if so is there a known workaround!
I'm using the Delphi 2010 Rad Studio on Windows 7 64 bit.
A few times when editing the IDE hangs and I can't do any action either by keyboard or mouse. But there is a error-beep sound from windows like there is a modal window open somewhere, but hidden behind the ide it self.
Only by ending the ide via Task manager can I make this hidden modal window visible.
I see this often with various other dialogs as well.
Pressing "Alt-Tab" and reselecting Delphi you will cause the dialog to appear in the front again.
Note: This happens with other versions of Delphi as well.
I have the same problem with older versions of Delphi like D6.
My solution is use another tool like WinExp –Windows Explorer– or WinResQ to explore the existing active windows on system and reactivate it (BringToTop).
With this solution I get the Delphi IDE on Top and appears the window that cause the lock. This is the only option I have worked for me.
Regards.
Alt+Tab works, but you have to select another application, then Alt+Tab to return to Delphi, and then the dialog will show in front.
In a Delphi 2007 program I am using a TMainMenu referencing actions in a TAction list. I have prefixed the hotkeys of all main captions with an ampersand:
&File | &Edit | Ev&aluate | ...
In design view these hotkeys are underlined as I would expect, but when I start the program they no longer are underlined but they work nonetheless. In contrast to this, for all the submenu icons
&File
&New ...
&Open ...
the underline is shown as expected.
I am aware of the Windows pisplay properties option "Hide underlined letters or keyboard navigation until I press the Alt key." and have disabled it. In all other programs this works fine, including the Delphi IDE.
If I create a new VCL appliation and just add a TMainMenu and a few menu items, it works as expected.
This has me baffled, really.
Is there any property of the TMainMenu component or maybe an application option that I must change? The "Enable runtime themes" project option is grayed out for some reason, might that be the problem? If yes, what causes this?
This may not be a Delphi issue. I have just tried this with IE8 on WinXP. On my machine, with the display properties set to require the Alt key, the underlining works as expected. However, with the checkbox unchecked, the underlining never appears on the main menu items (even when using the Alt key), but always appears on the File,Edit,View etc submenus (as you describe) ........ unless Microsoft wrote IE8 in Delphi :-)
I asked the same question last year and there were some excellent answers:
Menu Accelerator Keys Not Showing Up Delphi 2009
In conclusion, it appears to be a Delphi bug, and I reported it to Embarcadero at:
http://qc.embarcadero.com/wc/qcmain.aspx?d=68816
However, they have no resolution to it, so unless others (maybe you) also complain, I don't expect it will get addressed.
Step's answer to my question refers to a possibly related bug reported on the Delphi forums:
ALT Key press causes controls to disappear under Themes in Vista and XP. This one is marked as "resolved" with several possible fixes listed in the comments. I have not had the opportunity to go through these.
By the way, since I asked that question last year, I got a new computer with Vista. The same problem still happens, even when the Vista Ease of Access Centre setting: "Underline keyboard shortcuts and access keys" is set. So the Delphi bug still exists.
I was very surprised to find the default was that this was unchecked. I guess in Vista, they want a cleaner looking menu with the assumption that not many people ever used the accelerator keys.
The easiest way to fix this problem seems to use TJvMainMenu from the jvcl instead of TMainMenu. I tried the current version 3.38, but it is possible that the problem was fixed already in earlier versions. Since I was using the jvcl anyway it does not add much to my program's size. Your mileage may vary though, the jvcl is a huge library.
Uses an empty image list for main menu, if it is possible. In this way you can force delphi to paint menu correctly. (But looks ugly in vista and w7)
Are you sure you don't have OwnerDraw set to true in the MainMenu?