Details/Scenario:
I am using Delphi XE6 with DevExpress 13.1.4 Components and i have a dxRibbon component.
The keytips that i mean is that F, Y1, Y2, Y3... 1, 2, 3... that shows up when i press alt on the keyboard as you can see below:
Question:
I want to disable the KeyTips of my Ribbon(the one that shows up when i press alt on keyboard), i have tried so many ways but i am unable to disable it, how it can be done?
Limitations:
I cannot modify the source of dxRibbon.pas or rebuild the DevExpress Components.
You have stated the following requirements:
Your program must use the DevExpress ribbon.
Your program must not modify the DevExpress ribbon.
This DevExpress support thread states that the keyboard shortcut tips cannot be disabled.
From which we can conclude that it is not possible to achieve your goals.
Step 1.
Use Andy's VCL VCLFixPack.
Step 2. Create a new Unit:
unit DxBarNix;
interface
implementation uses VclFixPack, dxBar;
var
NixKeyHook: TXRedirCode;
procedure NixKeyTip( AShowKeyTipWindows: Boolean);
begin
end;
procedure StartDxRibbonHook;
begin
HookProc(#dxBar.TdxBarNavigationController.EndKeyTipsWaiting, #NixKeyTip, NixKeyHook);
end;
procedure StopDxRibbonHook;
begin
UnhookProc(#dxBar.TdxBarNavigationController.EndKeyTipsWaiting, NixKeyHook);
end;
initialization
StartDxRibbonHook;
finalization
StopDxRibbonHook;
end.
After this, the KeyTips will disappear.
Related
I am developing a Delphi 10.1 VCL application for Windows.
For integer or float input I need a number input field which is connected with a slider. When the user changes the number in the input field the slider position changes accordingly. When the user changes the slider position the number in the number field is updated.
I can solve this by using a TEdit and a TTrackBar and add the necessary update functionality in their OnChange event handlers.
The problem is that I need many of such inputs on different forms. Therefore I would like to create a new component which combines the two controls TEdit and TTrackBar in one component.
Is the creation of a new component the best strategy for the multiple use of such a slider input?
What is the best way to create such a new component?
Is the creation of a new component the best strategy for the multiple
use of such a slider input?
Not necessarily true all the time. (by my standards at least).
What is the best way to create such a new component?
I know three ways to solve your problem.
Way number 1:
create the component using the new component wizard where you create dynamically the TEdit and the TTrackBar sub components in a TGroupBox descendant.
the following is how I would do that.
unit Combindedittrack;
interface
uses
System.SysUtils,
System.Classes,
Vcl.Controls,
Vcl.comctrls,
Vcl.StdCtrls;
type
TCombindEditTrack = class(TGroupBox)
private
{ Private declarations }
FEdit: TEdit;
FTrackBar: TTrackBar;
procedure EditOnChangeProc(Sender: TObject);
procedure TrackBaroOnChangeProc(Sender: TObject);
protected
{ Protected declarations }
public
{ Public declarations }
constructor Create(AOwner: TComponent); override;
destructor Destroy; override;
published
{ Published declarations }
end;
procedure Register;
implementation
procedure Register;
begin
RegisterComponents('Samples', [TCombindEditTrack]);
end;
constructor TCombindEditTrack.Create(AOwner: TComponent);
begin
inherited Create(AOwner);
SetBounds(0, 0, 250, 50);
FEdit := TEdit.Create(Self);
with FEdit do
begin
Text := ''; //<-- you control the appearence here
Top := 10;
Left := 10;
Height := 27;
Width := 50;
Parent := Self;
OnChange := EditOnChangeProc; // your Onchange event handler for the Tedit
end;
FTrackBar := TTrackBar.Create(self);
with FTrackBar do
begin
Top := 10; //<-- you control the appearence here
Left := 60;
Height := 30;
Width := 50;
Parent := self;
Onchange := TrackBaroOnChangeProc; // your Onchange event handler for the Ttrackbar
end;
end;
destructor TCombindEditTrack.Destroy;
begin
FTrackBar.Free;
FEdit.Free;
inherited;
end;
procedure TCombindEditTrack.TrackBaroOnChangeProc(Sender: TObject);
begin
// <-- track bar onchange handling here.
end;
procedure TCombindEditTrack.EditOnChangeProc(Sender: TObject);
begin
// <-- edit onchange handling here.
end;
end.
Way number 2:
Use frames like this (I'm on delphi 10 seattle).
File-->New-->Other-->(search for frames on delphi files).
Now add the edit and the track bar and set their Onchange events.
Save the unit.
on the tool palette (the standard component section) click on the frame component.
choose the frame you just created.
You will have a replica of the frame each time you use it.
Way number 3:
Use component template like this (again I'm on delphi 10 seattle)
Select your already created and modified tedit and ttrackbar.
On the toolbar's "component" click "create component template".
Name your template and press OK.
Select the Template palette and then your template.
Now notice that even your code (events) are added as well to your project.
Finally
With the level I have on delphi and the IDE I'm really unable to give you a clear answer to which is the best way but nevertheless I have shared all what I know that could help you.
edit: Since a lot of comments are insisting that the answer should state which is the best way to do this. this is the best way based on the following.
let's put some of the key point that should be accounted for when choosing
1. Ease of modifying the combined control(s) if you wish so (by my experience you will).
2. time needed to complete this task (it means the time it will take
you to fully complete the task with minimum debugging and coding).
3. general source code readability.
4. usefulness for the future of your projects.
Now lets start criticizing the three methods based on the those criteria.
Way number 1:
C1(criteria number 1): Just modify the the source implementation of the component and each replica/use will have the same effects and properties. However this is not the case for way number 3.
C2: It depends on your knowledge of component writing but for this component it took me 5 min to create it and I'm only a beginner in delphi. For the debugging if something went wrong and the problem is in the component implementation than you just need to fix once (see C1)
C3: their is no implementation in your form(s) source code for your component just add it to your form and every thing is hidden (for example add a tedit and go to see the implementation in your forms source).
C4: You are creating a component after all this will open the door for you to create your own set of components like the Flatstyle or Indy open source components. so next time you need some thing like this you just drop it in your form designer and you are done.
Way number 2: frames
C1: It is like way number 1 because you are creating a component but it is visually this time. modifying the source frame will change the effects and properties of the replicas, also you can add extra handling to your replicas.
the event handler of the replica's Onchange event is like this
procedure TForm1.Frame2Edit1Change(Sender: TObject);
begin
Frame2.Edit1Change(Sender); //<-- this is the original onchange event you setup at the beginning
//<-- you can extra handling here if you want one of the replicas to behave differently than the original
end;
C2: same time and maybe faster than way number 1.
C3: over all, it has the same out come as way number 1.
C4: unlike way number 1 you can not use frames created in project A in project B. So your coding and debugging will stay in project A.
Way number 3: component template.
C1: you are not creating a component you are creating a repleca/macro of the exact steps you did in your last project. changing one will not change the others they are separated.
C2: same time and maybe faster than way number 1.
C3: each time you add a template to your form the events code will be added (not a good view if it is a long Onchange code).
C4: You can use templates created in project A in project B. However what you wrote in project A will be in project B (see c1) even the references of variables that don't exist in project B (this can be hard to debug and misleading, considering the period of time between each use of the template).
Conclusion: each of the ways presented will consume time to code and debug and all of them will do the task, How ever for the sake of simplicity and the reuse with minimum risks Way number 1 is the safe choice here because it will give you the chance to update and upgrade safely. also debug faster.
the good thing also about way number 1 is that after a while when you will forget the implementation and how things are working internally. The only thing that should stay in mind is the purpose of the component because it will become one of the various component you use (you don't know how Tedit is implemented and you don't need to but yet you use it in every single project you create).
based on the criteria given Way number 1 is the best.
Maybe using a container control that contains both controls is a simpler alternative. I am using ccpack for this.
https://sourceforge.net/projects/ccpack/
Custom Containers Pack (CCPack) is an integrated tool and component mini-
library to produce and maintain composite controls (or simply “composites”)
and other containers (forms, data modules and frames). The process of
building composite components looks like ActiveForm and Frame creating, but
the result is the native VCL component. You can create new composites just
as usual forms.
You can create a Frame and then register that Frame as a component. The end result is very similar to creating a code only component where the sub components are created in the constructor (Nasreddine's number 1 option). However this method allows you to visually design the component and use the object inspector to create your event handlers.
Here is a Stack Overflow question that shows how to register the frame:
How to Improve the Use of Delphi Frames
I'm creating an application for Windows and OS X using Firemonkey Framework with Delphi 10.2 Tokyo and can't set application or form icon dynamically.
In VCL project I've used following code:
Form1.Icon.LoadFromFile()
or
Application.Icon.LoadFromFile()
But there are no such properties or methods in FMX. Is there any way to set project icon otherwise than in Project -> Options menu?
Add to your uses list {$IFDEF WIN32}WinApi.Windows,FMX.Platform.Win,{$ENDIF}
procedure setFormIcon(Form: TForm; FileName: String);
var Icon : NativeUInt;
begin
{$IFDEF WIN32}
ICON := LoadImage(0,PWideChar(Filename),IMAGE_ICON,0,0,LR_LOADFROMFILE OR LR_DEFAULTSIZE OR LR_SHARED);
SetClassLong(FmxHandleToHWND(Form.Handle), GCL_HICON, icon);
{$ENDIF}
end;
procedure TForm1.btn1Click(Sender: TObject);
begin
setFormIcon(Form1,'my icon path.ico');
end;
In the 10.2 Rio sources, I see that the function TPlatformWin.CreateWindow, which is used to create a window in the Windows, have only this line to provide a window's icon:
WindowClass.hIcon := LoadIconW(MainInstance, PChar('MAINICON'));
And function TPlatformWin.CreateAppHandle have an absolutely same code! So, we have not a direct way to set app or form icon through FireMonkey components.
At Windows You still can use WinAPI message WM_SETICON (SendMessage(Handle, WM_SETICON, ICON_BIG, MyIconHandle);), but I have not tried that and do not know any troubles in this way.
Also in Windows we may use TTaskbarBase and TPreviewClipRegion classes to the more precise and functional way of TaskBar interactions.
P.S. I do not know, what we have for same requirements at OS X.
I am migrating a VCL application to FMX. I need to know the class of a control that has focus. The application works with various dynamically created frames with numerous input controls.
In VCL I use the VCL.Forms.TScreen.OnActiveControlChange as this is the one place to consistently capture the active control. This event is not available in FMX.Forms.TScreen. What would be an alternative approach in FMX?
The most similar approach in FMX would be to listen to the TForm.OnFocusChanged event. From within the event handler you could then look up theTForm.Focused property.
Sadly in Delphi 10.3, the approach outlined by #iamjoosy fails spectacularly with an 'Access Violation' under certain circumstances (especially when TabControls / TabItems are used as containers for other controls).
The code I am using:
procedure TForm1.FormFocusChanged(Sender: TObject);
var
Control : iControl;
MyControl : TFMXObject;
begin
Control := form1.focused;
try
MyControl := TFmxObject(Control.GetObject);
form1.Caption := MyControl.Name + ' of type ' + MyControl.ClassName;
finally
MyControl := nil;
Control := nil;
end;
end;
Yet to add some intrigue, the above approach reverts to working fine if:
1) There's no TabControl/TabItem objects
2) If I add the following event handler to each child button (e.g. setting focus back to its parent TabItem):
procedure TForm1.Button2Click(Sender: TObject);
begin
TabItem1.SetFocus;
end;
Hoping someone can offer advice as to whether I'm doing something stupid, or whether I've run into an FMX bug.
I am working on a project using Delphi 7 and Delphi 2006, i am developing a component that will get certain system information.
Now the requirement is that after the component is installed on the system, there should be a menu item on the IDE , like this
and for delphi 7 like this
i have searched on the net about adding a menu item but i have not got anything to add an item to the IDE like the one EurekaLog has.
can any body tell me how to add the item like EurekaLog or mysql ?
is it some where in the registry?
To add a menu to the Delphi IDE you must use the Delphi Open Tools API. from here you can access the Main menu of the delphi IDE using a code like this.
LMainMenu:=(BorlandIDEServices as INTAServices).MainMenu;
or
LMainMenu:=(BorlandIDEServices as INTAServices).GetMainMenu;
And then add the menu items which you want.
Check these links for additional samples
Open Tools API Chapter 15: IDE Main Menus
Introduction to the Delphi Open Tools API
How can I add a menu item to the IDE’s main menu?
If you want to specifically add a menu item to the HELP menu, and also make it get removed when your package unloads, and handle enable/disable of the items, then this wizard code might be helpful. I took the sample wizard code that GExperts documentation shows as a starter project, and posted it up here as a slightly nicer start project. You can get started very quickly if you grab this code and just extend it:
https://bitbucket.org/wpostma/helloworldwizard/
What they mean by "Wizard" is a "simple IDE Expert", that is, something with a menu added to the IDE, that implements IOTAWizard and IOTAMenuWizard. This approach has many benefits and is the way that the GExperts wizards are written.
The core of the code is this starter wizard, which needs to be put into a package (DPK) and installed, and registered with the IDE:
// "Hello World!" for the OpenTools API (IDE versions 4 or greater)
// By Erik Berry: http://www.gexperts.org/, eberry#gexperts.org
unit HelloWizardUnit;
interface
uses ToolsAPI;
type
// TNotifierObject has stub implementations for the necessary but
// unused IOTANotifer methods
THelloWizard = class(TNotifierObject, IOTAMenuWizard, IOTAWizard)
public
// IOTAWizard interface methods(required for all wizards/experts)
function GetIDString: string;
function GetName: string;
function GetState: TWizardState;
procedure Execute;
// IOTAMenuWizard (creates a simple menu item on the help menu)
function GetMenuText: string;
end;
implementation
uses Dialogs;
procedure THelloWizard.Execute;
begin
ShowMessage('Hello World!');
end;
function THelloWizard.GetIDString: string;
begin
Result := 'EB.HelloWizard';
end;
function THelloWizard.GetMenuText: string;
begin
Result := '&Hello Wizard';
end;
function THelloWizard.GetName: string;
begin
Result := 'Hello Wizard';
end;
function THelloWizard.GetState: TWizardState;
begin
Result := [wsEnabled];
end;
end.
The registration code is not shown above, but is included in its own "Reg" (registration) unit if you download this from the link above. A tutorial link is on EDN here.
Simple task:
I would like to make a program (parent.exe). There are three buttons. When I click Button1, Form1 appears; when Button 2, Form2 appears; when Button3, Form3 appears...
Form1, Form2, Form3 are stored in three different dlls (Form1dll.dll, Form2dll.dll, Form3dll.dll).
I wanted to make parent program (parent.exe) run modular. I planned to add and remove dlls, but Parent.exe requires all dlls to be present, otherwise an exception occures.
How can I solve the problem?
Thanx
Here is code from parent.exe:
procedure ShowForm1;stdcall;external 'Project1dll.dll' name 'ShowForm1';
procedure ShowForm2;stdcall;external 'Project2.dll' name 'ShowForm2';
procedure ShowForm3;stdcall;external 'Project3.dll' name 'ShowForm3';
var
ParentForm: TParentForm;
implementation
{$R *.DFM}
procedure TParentForm.Button1Click(Sender: TObject);
begin
ShowForm1;
end;
procedure TParentForm.Button2Click(Sender: TObject);
begin
ShowForm2;
end;
procedure TParentForm.Button3Click(Sender: TObject);
begin
ShowForm3;
end;
The way you've got it set up, the program looks for the DLLs at load time. What you need is to set the DLLs up as plugins. Take a look at the JVPlugin framework in the JVCL. It has exactly what you're looking for.
Yes it can by having the EXE Dynamically load the DLLs using LoadLibrary and GetProcAddress. See http://www.scalabium.com/faq/dct0130.htm for an example.
Next you might run into other problems because the memory manager and types are not shared between the EXE and the different DLLs. You might need to take extra care to circumvent these problems or look for solutions. Like runtime packages/BPLs or special memory managers.