I'm coding with C++Builder 10.2.
Every time I load a picture to my TImage object, I get an "Invalid pointer operation" error:
This happens whenever I load an image, or even if I haven't loaded any, it happens when I move the blank TImage object.
I know it should be shared with Embarcadero devs/supports, but I can also share the error codes.
I have same problem with Timage on c++ builder 2010.
It seems that is IDE bug and we have to create and free memory used by Timage manually.
This problem will not occur in the new version of Delphi(Rad studio 11 alexandria)
Related
So I'm developing a graphic library providing a custom SVG image format which may be used within a TPicture, or any VCL component supporting a graphic image, like e.g a TImage. I wrote and maintain my library package since the XE7 compiler version, and my code is backward compatible until the XE2 version.
In order to declare my custom graphic format to the IDE, I call the following code from the initialization section of my graphic class
Vcl.Graphics.TPicture.RegisterFileFormat('svg', 'Scalable Vector Graphics', TWSVGGraphic);
However this seems to no longer works since the last RAD Studio 10.3.3 Rio version. I already faced a similar issue in the past, for which I could find a solution:
Delphi - How to correctly register a graphic class since XE8?
So, apparently Embarcadero changed the rules since the 10.3.3 Rio version. Once again. My graphic class is no longer registered correctly since this version. Sometimes it is, sometimes it isn't. For example, when I open my IDE for the first time, it isn't. When I try to debug my package in design time, it is. When I try to run a project, sometimes it is, sometimes it isn't.
Has someone faced a similar issue? Are the rules about the initialization section changed in the most recent compiler versions? Finally, what the hell is wrong with my code?
Or perhaps I still not understand how to correctly register a graphic class in Delphi, even after so many years. In this case, I would be very grateful if someone may explain me how to correctly register a graphic class, in order to never more facing a such issue in the future.
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
Can I get some code showing how to draw a bitmap/icon on the right-click context menu?
I have working code already for a DLL for the context menu, but it's just text. Example here: http://www.marcocantu.com/code/md5/TODOSHLL.htm
It seems you can simply use the SetMenuItemBitmaps API.
Edit: Here's a Delphi example.
Edit 2: Warning: I just noticed that the Delphi example leaks the bitmap handle and will probably crash the system eventually. The bitmap should be loaded only once in the constructor of the object (and better from its own resource, not from the file system) and released in the destructor.
I'm trying to use the Pegasus Imaging PrintPro v4 ActiveX control with Delphi 7 on a Win2K box. When I drop the ActiveX control on the form I get the extremely helpful error message
"Access violation at address 00000000. Read of address 00000000."
and the component doesn't appear on the form.
There are a bunch of other Pegasus Imaging ActiveX controls installed and they work fine.
Any suggestions on where to start troubleshooting, I'm not very experienced with ActiveX control (I usually go for native VCL only).
Lachlan
If you download the latest changes file it says that "Fixed an issue where the ActiveX DLL would not register on Windows 2000.".
You should try upgrading to the latest version.
Something in the control is not configured properly. You might not be able to "drop" it on the form, but might have to instantiate it manually. The access violation you are experiencing is the attempt to get the value out of a pointer which is null. Most likely the control has a required construction parameter which is not being set by the Delphi ActiveX component wrapper.
We have a Delphi 5 application, that is built without runtime packages, dlls or external resources (i.e. a single executable). when we install it on a clients PC we get the following error messages:
Class TListView not found
or
Class TImage not found
We have installed it on dozens of PCs before without incident, but this latest install is problematic.
The target PC is a fresh install of Windows XP (Service pack 3) with no other software installed.
It does not complain about all of the classes however just one or two. for example TPanel/ TForm/ TEdit are all OK.
Can anyone think what is causing this?
EDIT
The exe on the new PC is on 30 or so other PCs that I know of, ranging from windows XP Sp1,2,3, Windows Vista and Windows embedded. both old and new PCs were installed with an old version and then updated with the newest version. The only difference is that the version jump was higher for the latest install.
This is typically an error during the streaming of a .DFM. Usually this error occurs with TLabel components because many folks remove the TLabel fields from the form or frame in order to cut down on the clutter and reduce the instance size of the form. The common and confusing mistake they make, however, is that in their over-zealousness, they remove all TLabel references. That is when bad things start to happen. Let me run down how the streaming system locates a component's class.
Remember that the class reference in the .DFM is just a string. The streaming system has to convert this string into a class reference (TComponentClass). There are two mechanisms that the streaming system uses to do this. The first one is very simple and involves a global list of class references. You can call RegisterClass or RegisterClasses to explicitly make the streaming system aware of it. The second is much more subtle and not very well known; in fact it is all part of the "magic" of Delphi :-). When the compiler builds the form, all the fields that represent the components on the form are processed and an internal table is built as part of the RTTI or metadata for the form/frame/datamodule itself. This table contains a list of references to all the individual component types represented by the component fields. So even if a component is not in the global list, it can still be found by scanning through this compiler generated table. That is what the Classes.TReader.GetFieldClass() method does.
Back to my TLabel example, this problem is easily fixed by simply ensuring that at least one of a given component type has a field. So as long as there is at least field of type TLabel, all the other TLabels will load just fine. So in your case, make sure the TListView or TImage fields haven't been deleted.
Re0sless,
I suggest you open and close every form of your application and do a fresh build after that. If memory serves me well, that was the solution when we encountered similar problems.
You might also take a look at DFM Check to open and close all your dfm's automatically and at CnPack to help you clean your uses clause.
Regards,
Lieven
I think Lieven is definitely on the right track: simple base classes not being found during runtime are a Delphi (linker) problem. This exception is not caused by the Operating System.
My experience with similar problems: the linker generates a project with the units wrongly arranged.
Example: a form unit is linked in before the base units. Forcing the project to completely recompile/relink itself should make this exception go away.
A simple [Rebuild All] will probably not suffice. You might try to recompile without optimizations.
I have tried to reproduce this error but I have not been able to. The Delphi compiler/linker is one of the best - speed of compilation/speed of compiled exes - but this bug is definitely a show stopper.
Note: I have only experienced
this error in D5. Has anybody else
experienced this error with other
Delphi versions?
I had the same problem. Class TCheckBox not found. I usually edit large set of components through .DFM of form(for example renaming large amount of component). This error comes when I rename all CheckBox on my form through it .DFM.
I just cut all the checkbox and paste them again(So .DFM file is refreshed). The error disappeared.
I've seen a similar problem due to a file copy error. To make matters more confusing, the fault was on an intermediate media device. The issue was resolved by simply recopying the file from the existing release build.
It is probably impossible to confirm now, but it is quite possible that the problem was 'solved'; not because of the removal of an unnecessay uses clause item, but because it also involved a new copy of the executable.
The solution for all errors of this type "Class XXX not found" is simple. Open DFM file of a form in text editor and manualy remove the definition of the XXX object in it.
Change the name of the Form and save the .pas with other name. Change all references to create the new unit name if this is used in other units. Build All.
With this the error disappeared.