I am porting a VCL component to FMX.
I already made the same functions as the previous VCL component. And I can install my new component and use it.
The problem is that my new component gains a new child component whenever I close and open the project again. Furthermore the number of these child components increases whenever I close and open the project.
So I made the component try to delete these object when created. But I could not solve this problem.
Can anyone help me?
I found the solution by setting the component's stored property to false.
Edit1->Stored = false;
I guess Stored was causing the duplicate components. Changing Stored to false avoids that.
Related
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
I have created a Tframe unit with visual and DB controls. I registered the frame as a component using the sprig approach. The TFrame has a few published boolean properties.
Everything works OK, except I have noticed that if I start the IDE and open a project that uses that component, the IDE complains about the "unknown" published properties. And if one looks at the DFM, Delphi has changed the definition for the frame within the form it is embedded in from "object ..." to "inline ...". If I just close the project, without saving, and re-open it, all is good.
It only happens on the first project open.
Any suggestions would be appreciated.
The thing here is that registering a TFrame does work, but publishing properties almost always does not. I say "almost always" as i had this kind of issue in the past (Delphi XE2 as far as i remember) and there seems to be a bug in the designer deeply hidden somewhere. Debugging this issue gave me no results back then.
I suggest you simply move the published properties to public and set these properties in source code directly. This is a workaround but it works.
I recently modified some old UI code using Delphi's VCL to use ADO instead of BDE. One of the screens used a TDBGrid control to modify the underlying DataSource, but it appears that is no longer possible to edit the values in the grid. Here is how I have it configured:
TDBGrid->TDataSource->TADOTable
I found this post on another forum that seemed related:
http://coding.derkeiler.com/Archive/Delphi/alt.comp.lang.borland-delphi/2009-08/msg00023.html
Is this a limitation of ADO? Or do I simply need to change the settings of a control somewhere? (cursor type or something?)
Okay, I solved the problem. When I converted the project from Delphi 6 to Delphi 2007, it changed the Options property of the TDBGrid control to seemingly random values (perhaps some defaults?). In this case, the dgEditing option was set to false.
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.
:)
Now this is a very puzzling matter I hope you can help me.
I have a custom component derived from TCustomControl that is included in a package. This package is correctly compiled and installed in D5. The package also requires the use of another library of components the ImageEn library.
I have an application that uses this component, Now until some day ago everything seemed to be fine, but now, after some recent changes to the component (mostly changing the name of the types it uses) I am having a very weird behavior going on. On the form where this component is placed Delphi will create I would say just for no reason a TImageEnIo component (from the ImageEn library) that was not even included in the dfm of the form.
Even more puzzling is the fact that this added imageenio component has no name, thus causing me a lot of trouble when I try to run the application (run-time error). If I delete this component it will reappear as soon as something is updated (for example if I switch between the text and the form of the dfm). Delphi just adds this thing on any form , where I use my custom component. This happens only when my custom component is present, other comps of the package do not generate this problem.
I noticed that it creates 1 of these empty TImageenio for each custom component I have on the form, and moreover if I switch back and forth between the text and the form views of the dfmit will add another imageenio component each time I do this.
Finally the problem is not dependent from the application as it will happen with any application as long as I add my custom component on a form.
Now I have been recompiling everything the imageen and my package many times, I have even tried to restore an older version of the component but the problem persisted (I am quite sure I hadn't experience it with the older version), I have tried anything conceivable but I cannot figure it out. I am at a complete loss, please advice If you need more info please ask, I will try to explain better.
Many Thanks to those who will take the time to answer.
It would seem that the problem was introduced by recent changes in your custom component.
You should use your revision control system to go back to a known good version. Then advance to intermediate versions of the code, perhaps using a binary search for efficiency. Once you've isolated the revision which introduced the bug then you should be able to study the code changes in that revision and identify the problem.
Wild guess: Your custom component directly or indirectly instantiates a TImageEnIo with the wrong Owner. Instead of using Self (i.e. the custom component instance) it uses its Owner property, which points to the form it is sitting on.
The first thing I would try would be to start a new application, create one of your custom controls at run time and put breakpoints on the third party source code where the TImageEnIo component is instantiated, constructor of the component would be fine. If the design time behavior is exhibited at also run-time, the breakpoint would be hit and you would be able to figure out the code part creating the component from the stack trace.
Otherwise, it is possible to debug design-time behavior by debugging the IDE with another instance of the IDE, but I don't know how it can be done with D5.