Borland C++ Builder: Some UI-Events not available anymore? - c++builder

I'm currently porting old code from Borland C++ Builder 5 to C++ Builder XE (the newest version). There seem to be a lot of properties and some events that are not anymore supported in XE. Most of them have been set to default values anyway, so it was no problem to remove them. Now, however, I have encountered the following problem: The event OnKeyUp is not available for TPanels anymore! Why is that? How can I fix this? And how did an OnKeyUp event on a TPanel work anyway?

The OnKeyUp event still exists. It is protected in TControl, as it always has been. Descendants choose whether to promote it to public/published access. That has not changed. TPanel did not promote any of the OnKey... events in BCB5 (or any other version), so I don't know whay you could have been using before.

Related

Delphi - How to correctly register a graphic class since XE8?

I'm writing a Delphi package, which provides a new custom TGraphic object, allowing to read a new image format in VCL components like TImage.
I originally developed this package with RAD Studio XE7, and it worked well. However I migrated recently to a newer RAD Studio compiler version, and although my package continues to work properly on that new version, I noticed a strange bug that never appeared before.
I have a form with several components, some of them are TImage components. Immediately after opening the IDE, the first time I open my project in design time, all the TImage components containing my custom TGraphic component loose their content. If I close then reopen the project, the images reappear, and the bug no longer happen until I close and reopen my IDE.
I dug in my code to understand what may cause the issue. To register my custom TGraphic component, I use the class initialization section, in which I wrote the following code:
initialization
begin
Vcl.Graphics.TPicture.RegisterFileFormat('svg', 'Scalable Vector Graphics', TWSVGGraphic);
end;
However I found that, since the XE8 compiler version, the TImage constructor is called before my initialization section, causing thus apparently the above mentioned issue. All the compiler versions since XE8 are affected, but this bug never happened on XE7 or earlier. So something changed since XE8.
Here are my questions:
Is the way I use for register my custom graphic class correct?
If not, what is the correct way to do that?
As something seems different since XE8, what it the new correct manner to register my graphic component?
Did anyone else faced the same issue? How he resolved it?
Is this may be a new RAD Studio bug, or the issue is rather on my side?
This is most likely a side effect of the smart loading the IDE applies to design time packages. You can overwrite this behavior by calling ForceDemandLoadState(dlDisable) during the Register procedure of your package.
More about this can be found in the documentation of more recent versions of Delphi than XE8: Explicitly disabling smart loading of components in a design-time package

How to patch TSpinEdit to use Vista/Win7 visual style?

Win7 must give ok style for TSpinEdit, but I see outdated style:
So arrows are not themed, and buttons are old.
I use Delphi7. How to patch VCL to fix style?
OK is:
I don't know if Delphi 7 already had it but you can use TEdit in combination with TUpDown and then set the Association property of the TUpDown to your TEdit.
TSpinEdit is a custom VCL control. There is no Windows control with that functionality. Even in the latest version of Delphi it looks exactly the same as in Delphi 7. And it's really rather ugly isn't it?
The control, in modern Delphi, is implemented in a unit named Vcl.Samples.Spin. Looking at the documentation for the Vcl.Samples namespace we have:
Contains the units for several sample VCL components delivered with RAD Studio - a calendar, an outline, a gauge, and a spinbutton.
The unit will be named differently in Delphi 7, but the principle is the same. These are sample controls, supplied with source code.
So, what you may do is take a copy of the TSpinEdit code, and modify the painting. Change the button drawing to be how you wish it to be.

THotKey does not work anymore under Delphi XE

I have upgraded an old project from Delphi 7 to Delphi XE.
The project has (among others) some THotKey controls. Under Delphi 7 the THotKey controls are working ok. But under Delphi XE they are like disabled. This means that they show nothing inside even if a shortcut (Alt+A for example) is assigned to them and I cannot edit them.
Anybody else has this issue?
Update:
I deleted ALL controls and all code from that project. Now I have ONLY the main form and a single THotKey control. Basically, after deleting all the controls my project is like a brand new created project without a single line of code. But the THotKey is still not working under Delphi XE and still works under D7.
Cause found (Delphi bug)
I compared my project with a new created project. I have seen that the old form had the 'double buffering' option set while in the new project this was not on, so I manually turned off this option in my old form. Guess what? The THotKey works!!!!!!! Every time I turn the 'double buffering' on, the THotKey goes ape.
Confirmed
Yes (by Andreas Rejbrand)
Solution (partial):
I have seen that it is not actually main form's DoubleBuffered property that causes this but rather THotKey's. So it is enough to turn off this property for THotKey, not for entire form. I think I can leave with that.
:)

Is there a Delphi option to 'lock' the design (layout) of a form against accidental changes?

After years of Delphi development I now have hundreds of forms shared throughout our Applications. Compilation ranges from Delphi 7 through to XE, thus one form might be opened in any IDE. The well-known Explicitxxx property addition after Delphi 7 has solutions to avoid a form accidentally acquiring properties that earlier compilers can't process (e.g Andreas's DDevExtensions) but I'd like a more positive 'switch' that prevented Delphi from making or saving any form modifications at all. Period.
Of course you could use the read-only flag, and a version control system provides additional means particulay of seeing that such a modification has occured. What I'd really like though is a {$LockDFM} switch that I could put in the form's unit, or a context menu option when viewing the form layout.
Can anyone think of a neat way of achieving this?
Thanks
The only thing I can think of (other than the read-only/VCS options you mentioned) is the Edit menu's Lock Controls option. This sets a flag that prevents controls from being moved around. I'm not sure how much good it would actually do, as I've never tried it; I just know it's there.
Helo
I am pretty sure that Delphi has no such a thing. I have been searching for a solution to this problem as well.
But, theres one thing you can do: You can write your own Delphi addon using OTA (Open Tools API). I know that there are a few classes which are able to notify you when something are about to be saved. You can intercept this event and decide if you wanna save it (in your case, if it is a DFM).
BTW, if you have plans to do such component, tell me. :)
EDIT:
I have found a piece of code that may help you. Extracted from http://www.gexperts.org/otafaq.html
TMyFormNotifier = class(TNotifierObject, IOTANotifier, IOTAFormNotifier)
protected
procedure FormActivated;
procedure FormSaving;
procedure ComponentRenamed(ComponentHandle: TOTAHandle; const OldName, NewName: string);
end;
In design time there is Edit->Lock Control.
LE: this is only for resizing/repositioning the controls on the forms. Concerning the ObjectInspector I don't know if there is anything that can 'lock' the values set there(so the developer can not change them).
Basically, no. Aside from the f'ing (pardon my french) explicit size and position properties which IMO never should have been in the .dfm, there are some third party components will change stuff just by you viewing the form. F.x. TMS components will update a version number even if you didn't change a thing since the previous version of their components.

One project in Delphi 2007 doesn't show procedure name in the IDE Obj Inspector's Events

I have a Delphi project in 2007 that doesn't show the procedure names in the Object Inspector's Events such as Form OnClose, OnCreate or OnShow in the IDE. The code is there and if you click on OnCreate (for example) you are taken to the code and the IDE fills in the name of procedure. However on reload, the procedures are missing from the IDE again.
This same project causes various error messages when Delphi closes also, but I am not sure if this is related (no other project developed under this Delphi does but this one is the largest app and uses several 3rd party add-in libraries).
I have moved this app to various Delphi 2007 installations and it reacts the same, so it isn't a corrupt Delphi situation. Is there any way to rebuild or fix a corrupt project like this? Any help would be appreciated.
I would try to remove all the files and keep only the dpr and the pas/dfm files in case it's a corrupted project file.
I would also double check if there is any Form inheritance mess, as I have seen somewhat similar issues with the inherited event handlers. (look at the dfm files directly)
Try delete all the .DCU's, close Delphi, restart Delphi then rebuild your project.
Delphi's IDE takes several liberties with your code without warning you.
In particular : if you have a callback (eg: "TMyForm.FormCreate") linked in the dfm, and the IDE detects that the function's body is empty, when you save your unit, the ide removes the declaration and the implementation before saving your file.
Adding anything (even a simple "//") in the function's body prevents this : try typing some code or some comment in your function before closing your Delphi.
As for errors when Delphi closes, there can be so many reasons.
Do you have any third-party components or experts installed ?
Have you tried installing IDEFixpack for D2007 ?

Resources