I start with a new Delphi VCL application, add Menus to the uses clause, drop a label on the form, and assign the form's OnShortCut event:
procedure TForm1.FormShortCut(var Msg: TWMKey; var Handled: Boolean);
begin
Label1.Caption := ShortCutToText(ShortCut(Msg.CharCode, KeyDataToShiftState(Msg.KeyData)));
end;
On XP, this works correctly for all shortcut key combinations that I've tried, including Shift+Ctrl+0. On Vista and Windows 7, the test application displays Shift+Ctrl+1 through Shift+Ctrl+9, but not Shift+Ctrl+0. Other combinations like Shift+0, Ctrl+0, and even Shift+Ctrl+Alt+0 are displayed fine.
Running the application under the debugger, I find that the OnShortCut event is never fired with Msg.CharCode = Ord('0') if both the Shift and Ctrl keys are held down while the 0 key is pressed.
The Delphi IDE has the same problem under Vista. Ctrl+Shift+1 sets bookmark 1, but Ctrl+Shift+0 does not set bookmark 0, which it should.
I've tested this with Delphi 2007 and 2010 on virgin installs of Windows Vista and 7 in VMware, so there's no 3rd party software trapping the keys. I haven't tried any other development tools to determine if the problem is with Delphi or with Vista itself.
Shift+Ctrl+0 is preassigned in Vista to the input method editor (IME) :
http://support.microsoft.com/kb/967893
This will solve your problem but will impact users of IMEs (mostly asian versions), so you should consider not using this shortcut.
It seems you're not the first to ask this, I found this thread on the How-To Geek Forums.
Then I found this MS knowledge base article:
"Input method editor keyboard shortcut (CTRL+SHIFT+0) switches the input language in Vista"
It is used to switch between languages. There is a workaround to turn this off. I just tried it and it works, the application now recognises Ctrl+Shift+0.
Try the old school Ctrl+K Ctrl+0 to set bookmark 0.
Related
For example: I define a ClientSocket1 variable in TForm1, and use ClientSocket1 in TForm1.Button1Click procedure:
procedure TForm1.Button1Click(Sender: TObject);
begin
if ClientSocke{ready to completion} then
end;
I press Ctrl+Space , But System Input Method was shown instead of completion，
please looking following gif animation screen record for explanation(please note the right bottom corner of the input method activity)
In Lazarus , I can use Ctrl+W to complete related variable in Unit, However I cannot do the same operation in Delphi, and the Delphi CTRL+Space is conflict with system input method.
If you want to change the default hotkeys for Delphi code editor there are few available presets in Tools -> Options -> Editor options - Key mappings.
http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Key_Mappings
It is possible to install additional presets through Open Tools API.
Amongst the provided presets are also New IDE Emacs and New IDE Clasic which are such custom key mappings installed into Delphi IDE through the Open Tools API.
According to documentation you can find ready examples for changing these in Samples > Delphi > VCL > ToolsAPI > Editor KeyBinding, but I can't find such example on my computer. Perhaps it is because I only own Professional edition of Delphi.
http://docwiki.embarcadero.com/RADStudio/Tokyo/en/New_IDE_Classic_and_New_IDE_Emacs_Keyboard_Shortcuts
it is bug in Delphi IDE,
only close the Delphi and restart it again
Create a new VCL Forms application
On the main form add a Tbutton and a TSaveDialog
Set "ofOverwritePrompt" to True in properties for the SaveDialog1
Use:
procedure TForm1.Button1Click(Sender: TObject);
begin
SaveDialog1.Execute();
end;
Run the app. Press the button to execute the save dialog. Try to save to a file that already exists.
A message box appears if you want to replace the file. Press cancel. All fine so far. Close the app.
Go to Project/Options/Application/Appearance and select a Custom style (e.g. Amakrits). Set Amakrits as the default style.
Run the app as in #5 above. Only a small bit of the message box will be shown. You will have to press Enter to be able to continue.
(Using a TFileSaveDialog will give the same result)
If I compile and run the app using Delphi XE8 it will be ok since the save dialog window seems to use the default windows style even if another style is chosen.
Edit:
I have Windows 10 pro. Source compiled as win32 with Delphi 10.1 Berlin.
The replace message box is partly hidden. Only a small top left part is shown, see figure.
And here it is compiled with XE8 win32:
Ps. I am using the default 100% scale factor.
Compiling with win64 (Delphi 10.1 Berlin) seems to be ok:
So, compiling to win32 does not work for me, but 64-bit will. Any clues?
Edit: Trying with "GetSaveFileName(OFN)" will also not work for me in win32 (win 64 is ok):
You can avoid this issue using the dialog styling code of the VCL Styles Utils project.
Just Add these units to your project.
uses
Vcl.Styles.Utils.Menus, //Popup and Shell Menus (class #32768)
Vcl.Styles.Utils.Forms, //dialogs box (class #32770)
Vcl.Styles.Utils.StdCtrls, //buttons, static, and so on
Vcl.Styles.Utils.ComCtrls, //SysTreeView32, SysListView32
Vcl.Styles.Utils.ScreenTips, //tooltips_class32 class
Vcl.Styles.Utils.SysControls,
Vcl.Styles.Utils.SysStyleHook;
{$R *.dfm}
procedure TForm26.Button1Click(Sender: TObject);
begin
UseLatestCommonDialogs := false;
SaveDialog1.Execute();
end;
I cannot confirm the problem, and all looks well here, (32 bit executalbe, themed with Amakrits, compiled with 10.1 Berlin, on Windows 7, 100% scaling) but you could try this:
uses ... Winapi.CommDlg;
...
var
OFN: TOpenFileName;
begin
FillChar(OFN, SizeOf(OFN), 0);
OFN.lStructSize := SizeOf(OFN);
OFN.nMaxFile := MAX_PATH;
OFN.Flags := OFN_OVERWRITEPROMPT or OFN_HIDEREADONLY or OFN_ENABLESIZING or OFN_EXPLORER;
GetSaveFileName(OFN);
end;
The result is an Amakrits-themed, new Explorer-like save dialog, which works fine (for me). Only the two round, blue "back" and "forth" (<- and ->) buttons at the top left of the dialog look a little weird.
But I did not try this with custom scaling settings (e.g. Medium 125% in the Control Panel -> Display panel, etc.). I think this could influence such things.
Update
I just tried to use SaveDialog1 (commenting out the OFN code above) with custom Display scaling (125%). All looked fine, so that is not it. Also when I use the OFN code, all looks fine (actually, better, i.e. no XP style dialog, but a real Explorer-like dialog instead).
If I set "Enable High-DPI" to true in Project/Options/Application it will work (replace box properly displayed). Disabling it will cause the problem (both in win32 and win64).
For the record, I had exactly the same problem (Delphi 10.1 Berlin, compiling on Windows 10 64 bit, 100% screen settings, compiled for 32 bit target). Enabling or disabling High-DPMI awareness didn't help.
A workaround is to disable styles for dialog boxes before executing the TSaveDialog (or TOpenDialog) like this:
TStyleManager.SystemHooks := TStyleManager.SystemHooks - [shDialogs];
The file dialog itself will still be themed. You will get standard Windows-style message boxes in case an overwrite prompt (or create prompt) pops up, but they will be large enough for the user to read and click them. After the file dialog has finished, you can enable styled dialogs again by re-adding shDialogs to SystemHooks if needed.
Create a new VCL Forms application
On the main form add a Tbutton and a TSaveDialog
Set "ofOverwritePrompt" to True in properties for the SaveDialog1
Use:
procedure TForm1.Button1Click(Sender: TObject);
begin
SaveDialog1.Execute();
end;
Run the app. Press the button to execute the save dialog. Try to save to a file that already exists.
A message box appears if you want to replace the file. Press cancel. All fine so far. Close the app.
Go to Project/Options/Application/Appearance and select a Custom style (e.g. Amakrits). Set Amakrits as the default style.
Run the app as in #5 above. Only a small bit of the message box will be shown. You will have to press Enter to be able to continue.
(Using a TFileSaveDialog will give the same result)
If I compile and run the app using Delphi XE8 it will be ok since the save dialog window seems to use the default windows style even if another style is chosen.
Edit:
I have Windows 10 pro. Source compiled as win32 with Delphi 10.1 Berlin.
The replace message box is partly hidden. Only a small top left part is shown, see figure.
And here it is compiled with XE8 win32:
Ps. I am using the default 100% scale factor.
Compiling with win64 (Delphi 10.1 Berlin) seems to be ok:
So, compiling to win32 does not work for me, but 64-bit will. Any clues?
Edit: Trying with "GetSaveFileName(OFN)" will also not work for me in win32 (win 64 is ok):
You can avoid this issue using the dialog styling code of the VCL Styles Utils project.
Just Add these units to your project.
uses
Vcl.Styles.Utils.Menus, //Popup and Shell Menus (class #32768)
Vcl.Styles.Utils.Forms, //dialogs box (class #32770)
Vcl.Styles.Utils.StdCtrls, //buttons, static, and so on
Vcl.Styles.Utils.ComCtrls, //SysTreeView32, SysListView32
Vcl.Styles.Utils.ScreenTips, //tooltips_class32 class
Vcl.Styles.Utils.SysControls,
Vcl.Styles.Utils.SysStyleHook;
{$R *.dfm}
procedure TForm26.Button1Click(Sender: TObject);
begin
UseLatestCommonDialogs := false;
SaveDialog1.Execute();
end;
I cannot confirm the problem, and all looks well here, (32 bit executalbe, themed with Amakrits, compiled with 10.1 Berlin, on Windows 7, 100% scaling) but you could try this:
uses ... Winapi.CommDlg;
...
var
OFN: TOpenFileName;
begin
FillChar(OFN, SizeOf(OFN), 0);
OFN.lStructSize := SizeOf(OFN);
OFN.nMaxFile := MAX_PATH;
OFN.Flags := OFN_OVERWRITEPROMPT or OFN_HIDEREADONLY or OFN_ENABLESIZING or OFN_EXPLORER;
GetSaveFileName(OFN);
end;
The result is an Amakrits-themed, new Explorer-like save dialog, which works fine (for me). Only the two round, blue "back" and "forth" (<- and ->) buttons at the top left of the dialog look a little weird.
But I did not try this with custom scaling settings (e.g. Medium 125% in the Control Panel -> Display panel, etc.). I think this could influence such things.
Update
I just tried to use SaveDialog1 (commenting out the OFN code above) with custom Display scaling (125%). All looked fine, so that is not it. Also when I use the OFN code, all looks fine (actually, better, i.e. no XP style dialog, but a real Explorer-like dialog instead).
If I set "Enable High-DPI" to true in Project/Options/Application it will work (replace box properly displayed). Disabling it will cause the problem (both in win32 and win64).
For the record, I had exactly the same problem (Delphi 10.1 Berlin, compiling on Windows 10 64 bit, 100% screen settings, compiled for 32 bit target). Enabling or disabling High-DPMI awareness didn't help.
A workaround is to disable styles for dialog boxes before executing the TSaveDialog (or TOpenDialog) like this:
TStyleManager.SystemHooks := TStyleManager.SystemHooks - [shDialogs];
The file dialog itself will still be themed. You will get standard Windows-style message boxes in case an overwrite prompt (or create prompt) pops up, but they will be large enough for the user to read and click them. After the file dialog has finished, you can enable styled dialogs again by re-adding shDialogs to SystemHooks if needed.
I just want to apologize in advanced if this question is already in another thread. I am also relatively new to Delphi.
Today I have seen an example Delphi program that has TButton components on it. The buttons have a pulsating blue effect that I assume is part of the Windows styling. There is absolutely no code written to make the button this way. I have searched for a possible setting, but to no avail.
Note: The buttons makes the effect at run-time and there is no custom components installed.
If someone could give me some information about how to do this without code, maybe just a setting would be great.
I am using Delphi 7 (2002).
Delphi Firemonkey (FMX) component framework has a TColorAnimation for which you can set properties like Duration, StartValue, StopValue, trigger etc. The FMX framework was introduced in Delphi XE2.
Blinking button demo
Now that you have clarified that you use Delphi 7 (please remember in future to indicate the version), here's an alternative that works in Delphi 7 (FMX is not compatible with Delphi 7)
var
b: boolean;
procedure TForm9.Timer1Timer(Sender: TObject);
begin
b := not b;
if b then
Button1.Perform(BM_SETSTATE, 0, 0)
else
Button1.Perform(BM_SETSTATE, 1, 0);
end;
Flashing is controlled by a TTimer, e.g 500 ms.
However, this doesn't fulfill your requirement of "There is absolutely no code written to make the button this way.", but I'm not aware of any way to achieve that.
HI
I'm using Delphi 2007 and have set the MainFormOnTaskBar property to true.
The issue that I'm having is this.
If you open a child window from the main form and then you show a message dialog from the child window you just opened. When you close the message dialog and then close the child window, the main form will be sent to the back of any other application you have on the screen.
This happens under windows Vista and Windows 7. Does anyone know why this is happens and how can I fix it?
I guess that would be QC66892-Closing forms deactivates the application, which appears to have been fixed with Delphi 2009 according to the report. At the bottom of the QC report you'll find a comment by Andreas Hausladen including a link to his fix of the bug. But you'd really want to utilize his VCL Fix Pack which includes many other fixes as well.
I've fixed this in two ways.
Firstly by adding stdcall to the end of DoFindWindow in Forms.pas as described by Andreas Hausladen. This handles when a child form is hidden (CloseAction = caHide) instead of released when closing the form.
Secondly - copied the code from TCustomForm.CMShowingChanged that calls FindTopMostWindow and then activates the window that was returned into TCustomForm.CMRelease.
(Edit: code block needs to be indented by 4 spaces)
procedure TCustomForm.CMRelease;
var
NewActiveWindow: LongInt;
begin
if Application.MainFormOnTaskbar then
begin
NewActiveWindow := 0;
if (GetActiveWindow = Handle) and not IsIconic(Handle) then
begin
NewActiveWindow := FindTopMostWindow(Handle);
end;
if NewActiveWindow <> 0 then
begin
SetActiveWindow(NewActiveWindow);
end;
end;
Free;
end;
This seems to have done it, I'll continue testing to make sure.
The PopupMode and PopupParent properties were added specifically to TForm to address this issue. Before showing the child form, set it's PopupParent to the main form, and it's PopupMode to pmAuto.
PopupParent specifically affects the Z-order of windows when other windows are shown.
The Delphi 2007 help has some documentation on these two properties, but you have to go through TForm to get to them. Use 'TForm,Pop' as your search topic (w/o the quotes, obviously ) to get there. The docs are a little confusing about PopupParent, because it discusses the effect that PopupMode has on the automatic assignment of PopupParent. A little experimentation after reading the docs should pay off, though.