I added a TOPenDialog component to a form and am writing the menu method to operate it. I copied code from a VCl project including the line openDialog1.Options := [ofReadOnly];.
The compiler rejects it since ofReadOnly (and other options) are not recognized. The TopenOptions type is included in VCL.Dialogs but does not seem to appear in the FMX version.
I am currently using the Delphi starter version which does not include the FMX.dialogs.pas file text so I cannot add the options into the unit. WIll including the VCL.dialogs file in the Uses section fix this? I have heard that it is not a good idea to mix VCL and FMX units together in the same program.
If you read Embarcadero's documentation, you will see that the FMX.Dialogs.TOpenDialog.Options property uses the same System.UITypes.TOpenOptions type that the VCL.Dialogs.TOpenDialog.Options property uses, so both dialogs have the same options available.
The reason your code is not compiling is because the TOpenOption enum has been declared with the {SCOPEDENUMS ON} directive enabled (see Scoped Enumerations). You need to prefix scoped enum values with their containing enum type name, eg
uses
..., System.UITypes;
OpenDialog1.Options := [TOpenOption.ofReadOnly];
Related
I am using Delphi 2010 and GExperts stable release 1.35
I am testing the "Replace Components" expert.
I add a main form and a secondary form. Each has three TEdits on it.
I use the Replace Components Expert to replace all TEdits with TRzEdit. I Check the Replace all components on all forms of the project.
It works, it replaces them all. However, it doesn't do anything to the DFM file. How do i make it replace those instances.
If i save, compile, or rebuild, i get errors.
If i try to view the form as text after replacing, i get errors.
Can someone explain to me the steps to make this work?
Thanks
I just tried it with Delphi XE and GExperts 1.35 and it does indeed crash now even after a single "Replace Selected". (It used to work fine in the past).
It seems that using the hidden menu Project | Clear Unit Cache just after Replace Components then doing a full build before trying any Save/Compile/View As Text... fixes the problem.
I think this menu is surfaced with cnPack. I don't have it and cannot guarantee, but you can easily do it yourself by adding the following unit in one of your installed packages:
unit FGEnableHiddenMenus;
interface
procedure Register;
implementation
uses
Classes, Forms, Menus;
procedure Register;
var
Comp: TComponent;
begin
//Make a hidden menu item visible
Comp := Application.MainForm.FindComponent('ProjectClearUnitCacheItem');
if Comp is TMenuItem then
TMenuItem(Comp).Visible := True;
end;
end.
Source: Brian Long's old goodies
Update:
I had to replace a couple of TEdit by TDBEdit on our main project at work and this trick worked.
But on a new Project with 3 Forms, it failed consistently to write/commit/save the changes on the last Form (same environment).
FYI, I tried with and without DDevExtensions 2.5 and IDEFixPack 4.6.1
Update2:
Went digging in the GExperts forum as suggested by Ulrich and finally found a possible explanation. The new property Touch does not like being copied from one component to another when the source is destroyed (causing the AV).
The suggested workaround is to do a bidirectional mapping in the Expert Settings to disable the copy for this property:
You might be running into this bug while trying to copy the Touch property from the old to the new component, but it has a workaround you can fairly easily test:
http://tech.groups.yahoo.com/group/GExpertsDiscuss/message/3994
Details:
There is a limitation/bug in Delphi 2010 and XE where if you assign a
Component.Touch property from one component to another and destroy the
original component that the new component becomes corrupt (it isn't
like component/interface references, where they either auto-correct
themselves or are reference counted).
For the moment, you can assign a bi-directional replace component
property map from TPanel.Touch to TGroupBox.Touch (use the two components being replaced in your specific case) that is marked as
a disabled property map, and that will work around this problem. Our next release
will not try to assign that property any longer.
GExperts 1.36 is also now available and includes a workaround for this issue. The workaround has been in the GExperts version control system and in testing for several weeks already.
I have forms in my application that I derive from a common ancestor, like:
TAtFormBaseIW = class( TIWAppForm )
and
TAtFormExplorerIW = class( TAtFormBaseIW )
This works for certain forms, but not for others.
Let me make a wild guess: it seems to work for all forms that where created in Delphi prior to IW 10, but not for forms I created with IW 10. What happens with newer forms: HWenever I want to load them into the IDE, they are interpreted as win32 forms, some properties are ignored (all typical win32 properties such as ClientWidth), and I am told that I cannot put IW components on these forms.
Making them direct descendants of TIWAppForm, saving them and using a normal text editor to change them back works. After a recompile they show up fine in the browser, but never in the IDE.
Any idea of what is happening?
Mea culpa, mea maxima culpa. This problem has nothing to do with IntraWeb, but with the way a derived form should be added to the project.
Instead of just changing TIWAppForm to TAtFormBaseIW, after having added a new form to the project, I should do this:
Select in the IDE
File / New / Other / Inheritable Items
and then the base form you want to derive your form from.
If you want to turn an existing form into a derivate, also change the leading key word object in the dfm file to inherited.
You can read about this here.
I am trying to get rid of lots of warnings in a project after converting it from BDS 2006 to Delphi 2009.
The project needs a type library named MSHTML_TLB. The source file mshtml_tlb.pas is an incredibly large file (about 16MB and >440.000 lines of code) which is generated when the Type Library is imported into Delphi 2009.
This file produces many warnings when building the project:
W1010 Method 'ToString' hides virtual method of base type 'TObject'
Since Delphi itself has created that file, I am wondering why these warnings come up and if I should just ignore them?
If so, is there a way to disable this kind of warning just for this file?
Delphi introduced this virtual method in TObject. Your declaration of ToString in a derived class does not use override so the ToString method of TObject is not accessible anymore. Adding override to your ToString method should solve the problem unless you declared your method differently.
Write to the beginning of the MSHTML_TLB.pas file this line (in bold):
unit MSHTML_TLB;
{$WARNINGS OFF}
and at the end:
{$WARNINGS ON}
end.
As a last resort, you can hide warnings. In Delphi 2010 this is in Project Options/Delphi Compiler/Hints and Warnings. I think this particular warning is "Redeclaration of a symbol hides a member in the base class".
Start up Delphi.
On the "Component" menu in the main toolbar select "Import ActiveX Control..."
In the list box scroll and and select "Microsoft HTML Object Library".
The "Class names" should then list "TScriptlet".
Click "Install...", then click "OK" on the "Install" form that appears and "Yes" on the confirm prompt.
I am writing a class to handle security in my executable (checking serials, trial date check etc). After I compile the executable (even in Release build, with all debug and RTTI generation turned off), when I open it in NotePad and search the method name in the raw data, I can see all the names of the methods that assemble my class. There are no published members in any class in the code base.
This is bad for protection. Is there any way to tell Delphi not to store method names in the executable ? Why is it storing them at all if there is no RTTI needed and no COM explosion? Is there any compiler option controlling this?
It may be that ANY method of ANY class in the target executable is stored inside the executable in text form. Apparently this is caused by the extended RTTI being turned on by default for all classes in Delphi 2010.
If you are asking about the extended RTTI in Delphi 2010, it can be switched off by
{$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}
see also docwiki.
Also strip relocations, take up the following in the project's dpr file:
{$IFDEF RELEASE}
// Leave out Relocation Table in Release version
{$SetPEFlags IMAGE_FILE_RELOCS_STRIPPED}
{$ENDIF RELEASE}
... and don't forget to turn off "td 32 debug info" (in older versions) or debug info in the linker tab in later ones.
What you probably will see is your form definition as a resource (eg the binary represetation of the DFM files of your project).
If you don't want to show these (for the serial info screen etc) you shouldcreate these forms "in code". Eg create a TForm, place a TButton and TEdit onto it, attach the event handlers in code.
To do this in a handly way: start with a form and create the DFM. When vieing the form, choose View as text from the context menu and you will know what things you should copy into code. And make sure NOT to place any varaiablerefernces under de published (always put public/protected/private as the first line within your class definition.
The compiler (dcc32.exe) in Delphi 2007 and higher has an option
-NS<namespaces> = Namespace search path
Is this releated to the compiler options 'Default namespace' and 'Namespace prefixes' in the project options dialog? Search 'path' sounds like a folder (directory) name, so I am not sure what this option is good for.
The purpose of this setting is to provide a list of prefixes that are used to search for unit names which are not fully qualified. E.g., in older Delphi versions, you would typically have something like this in your unit's interface section:
uses
Windows, SysUtils, Classes;
That would instruct the compiler to use the Windows, SysUtils and Classes units when trying to locate unknown identifiers.
In more modern Delphi, it works much the same way, except that the units are no longer called Windows or SysUtils, but rather WinApi.Windows or System.SysUtils. If you use just Windows or SysUtils, they wouldn't be found.
But, of course, no one wants to rewrite all of their source codes to the new unit names. Delphi compiler provides an option to specify the namespaces to be searched by default if an exact unit name is not found. In the example above, we could set the default namespaces to WinApi;System and then all of the units would be properly found, because the Delphi compiler would try to search for Windows (not found), WinApi.Windows (found - go to the next unit), SysUtils (not found), WinApi.SysUtils (not found), System.SysUtils (found - go to the next unit), ..., System.Classes (found - all required units found).
You don't usually deal with this if you use the GUI because the namespace list is a part of the project file and a sensible default is provided. The same applies if you build your applications from command line using msbuild.exe and the project file. But if you use dcc*.exe and the *.dpr, then you do have to provide the namespaces that you want to be applied automatically - and that's what the -NS option is for. In our example, you could use -NSWinApi;System.