Release Notes for Appmethod 1.15

From Appmethod Topics
Jump to: navigation, search

These Release Notes contain important information that might not appear in the main product documentation. We recommend that you read this page in its entirety. Read the most current version of these notes on the docwiki at Release Notes for Appmethod 1.15.

Installing, Uninstalling, and Upgrading Your Product

Before you install, uninstall, or upgrade the product, read the Install.htm and License.rtf files. The Install.htm file gives the system and free space requirements, and installation and upgrade procedures. License.rtf is your Software License and Support agreement.

Read the most current version of the Install.htm file on the docwiki at Installation Notes for Appmethod 1.15.

Here are other ways to access the Install.htm file:

  • Open the file
  • Click the Help button on the Install launcher
  • Open Install.htm in your product installation directory; by default, this directory is:
    C:\Program Files\Embarcadero\Studio\n.n
    • For more information about installation, deployment, and licensing issues, see the Install.htm, Deploy.htm, and License.rtf files that are installed by default at C:\Program Files\Embarcadero\Studio\n.n (on 64-bit Windows, the directory is Program Files (x86)).

FireMonkey Notes

iOS App Might Not Close/Reopen Properly After Running without Debugging on the Device

If you run your iOS app on the device without debugging and then kill the process of your application on the device, you will need to run the PAServer reset command if you want to run the process outside the IDE; type 'r' at the PAServer command prompt.

Names Must Be Assigned to All Components Before Creating a New View in the Form Designer

If you open an older FireMonkey app in XE7, you might encounter the following error message:

 Cannot inherit from form 'FormName".  It contains a component with a blank name property.

The new Views Inheritance system requires that you assign a name to all components before you can create a new View in the Form Designer.

Appmethod C++ Notes

Explicitly Instantiating and Exporting Template Members from Exported Classes

When you export a class that contains template member functions from a DLL or a package (using the __declspec(dllexport) directive or the PACKAGE macro, respectively), these members must be explicitly instantiated and exported. Otherwise, consumers of the exported class might run into unresolved external errors regarding the template member.


#define PACKAGE __declspec(package)
  int foo();
  template<typename T>
  int bar(T *p)
    return *p;

#include "mypackage.h"
int X::foo()
  return 7;

The above resides in a C++ package.

The following app invoking the bar member gets an unresolved external:


#include "mypackage.h"

int g = 6;

int main()
  X x;;
 Error: Unresolved external 'int X::bar<int>(int*)' referenced from C:\USERS\ADMIN_000\APPDATA\LOCAL\TEMP\MYAPP-233656.O

To resolve the error, add the following line to mypackage.cpp:

template PACKAGE int X::bar<int>(int*);

The added line explicitly instantiates and exports the member template used by the myapp.cpp source.

Downloading DirectX Header Files

We only ship DirectX headers inside the Microsoft Windows Platform SDK. If you encounter errors such as "d3d.h file not found", the HPP generated for that Delphi unit contains #include <D3D*.hpp>. You can do either of the following:

  • Add a {$NOINCLUDE Winapi.D3DX9} directive to the unit that uses the D3D unit and regenerate the HPP file of that unit. The regenerated HPP will not contain the #include <Winapi.D3DX9.hpp>.
  • Download the DirectX SDK that the D3D header relies upon. You can download the DirectX SDK for free from Microsoft. For more information, see Where is the DirectX SDK? (Windows).

Events with Structs or Sets of 5-8 Bytes Are Not Valid for BCC64

Events generated by the IDE that take a struct or set that is between 5-8 bytes are valid for 32-bit C++, but not valid for 64-bit C++. This only affects cases where the type is passed by value. For cases where the type is passed by reference, there is no difference between Win32 and Win64.

For example, an Access Violation occurs when accessing the TPoint &MousePos parameter of the OnContextPopup event, because the TPoint &MousePos parameter is invalid on the Win64 platform. If you look at the __closure type declaration, you can see the difference between Win32 and Win64. Here is the __closure declaration for the PopupMenu event of TControl:

#ifndef _WIN64
typedef void __fastcall (__closure *TContextPopupEvent)(System::TObject* Sender, const System::Types::TPoint &MousePos, bool &Handled);
#else /* _WIN64 */
typedef void __fastcall (__closure *TContextPopupEvent)(System::TObject* Sender, System::Types::TPoint MousePos, bool &Handled);
#endif /* _WIN64 */

To get the code to work for both Win64 and Win32, you must #ifdef the IDE-generated handler as follows:

#ifndef _WIN64
void __fastcall TForm46::FormContextPopup(TObject *Sender, TPoint &MousePos, bool &Handled)
void __fastcall TForm46::FormContextPopup(TObject *Sender, TPoint MousePos, bool &Handled)
  ShowMessage(System::String().sprintf(L"Mouse at (%d,%d)", MousePos.X, MousePos.Y));

Cannot Programmatically Assign IDE-Generated Event Handlers that Have Interfaces as Parameters

Delphi interfaces are exposed as templates in C++. That is, Delphi interface IFoo becomes _di_IFoo in C++. But the IDE is instead generating IFoo* in event handlers. This causes two problems:

  • The event handler generated by the IDE cannot be assigned to the event programmatically, because the compiler sees the mismatch in the event's declaration and the handler declaration.
  • The event handler does not get the prologue/epilogue code generated by the C++ compiler for Delphi interfaces.

NOTE: This issue affects newer runtimes like REST, FireDAC and even Live Bindings. All of these have events that have interface types as parameters. VCL, however, does not have events with interface parameters.

For example, following is a standard closure event handler (the added comment indicates the point of difference with the generated handler):

typedef void __fastcall (__closure *TFDConnectionRecoverEvent)(System::TObject* ASender, 
  const Firedac::Stan::Intf::_di_IFDStanObject AInitiator, // <<< ***
  System::Sysutils::Exception* AException,
  Firedac::Phys::Intf::TFDPhysConnectionRecoverAction &AAction);

But here is the IDE-generated event handler (also with an added comment):

void __fastcall TForm1::FDConnection1Recover(TObject *ASender, 
          const IFDStanObject *AInitiator, // <<< ***
          Exception *AException, 
          TFDPhysConnectionRecoverAction &AAction)

You can safely use the handler generated by the IDE. However, if you attempt to assign the handler programmatically, the compiler generates an error because of the mismatch between the closure and the handler's signature.

The Workaround: If you want to refer programmatically to the handler, perform the following steps:

  1. Clear out the event in the Object Inspector (the IDE will not delete the handler as long as it is not empty).
  2. Move the handler out of the __published section. (You can move it to the public, protected, or private section of the class.)
  3. Update the declaration and definition of the handler to match the closure declaration.
    For example, in the case of our example, replace IFDStanObject * with _di_IFDStanObject.

Now you should be able to assign the handler programmatically.

Object Pascal Notes

Cannot use 'absolute' Keyword in Interop between Object Pascal and Appmethod C++ 64-bit Windows

The "absolute" Object Pascal directive/keyword is not supported in the interface section of a Object Pascal app when run interop with Win64 C++. However, the "absolute" keyword can be used in the implementation section.

IDE Notes

In Multi-Device Form Designer, Can Only Delete a Component from the Master View

When you try to delete a component, such as a TButton, from a different view (not the Master view), the following error message appears:

 Selection contains a component, Button1, introduced in an ancestor and cannot be deleted

The solution is to delete the component from the Master view. For more information about views, see Form Designer.

Renamed iOS Project Might Fail at Run Time or When Debugging

Renaming a project in the IDE can cause an iOS app to fail at run time and debug time. To correct the issue, do the following:

  1. Select Project > Deployment.
  2. In the Deployment Manager, click the Revert To Default speed button.

Mobile Setup Wizard Content Is Blocked on Windows Server 2008

RAD Studio shows you the Mobile Setup Wizard when you are working on a mobile application and you:

  • Need to follow some configuration steps to continue.
  • Run into an issue and might need help.

You can also select Help > Mobile Setup Wizard to open the Mobile Setup Wizard.

When this wizard opens in Windows Server 2008, Windows shows an Internet Explorer dialog box. You must add the content of the wizard to the whitelist of Internet Explorer in order to see the content of the wizard.

You can see the mobile setup wizard here:

Database Notes

64-bit Windows C++ Application with a FireDAC Component Might Raise Error

The following error is raised when attempting to compile an application using a single FireDAC component, when the platform is Windows x64 with static linking:

c:\program files (x86)\embarcadero\studio\<n.n>\Bin\CodeGear.Cpp.Targets : warning : Warning: Out of memory
c:\program files (x86)\embarcadero\studio\<n.n>\Bin\CodeGear.Cpp.Targets(2751,5): error MSB6006: "ilink32" exited with code 2.

The workaround is to not link FireDAC statically in Win64 C++ apps.

Workaround for INI File Errors with FireDAC

In previous versions, FireDAC created INI files in "C:\Program Files", which in modern Windows versions is read-only for regular Windows users. If you are getting errors like "Can't modify file" when adding new FireDAC connection definitions using the Data Explorer or FDExplorer, then FireDAC INI files might still be located in "C:\Program Files". To resolve the issue, you should download and run the FDFixIni utility, which relocates FireDAC INI files to a correct location and updates the FireDAC registry. By default, the correct location is "C:\Documents and Settings\All Users\Documents\Embarcadero\Studio\FireDAC".

To resolve the issue:

  • download FDFixIni from the Registered Users site:;
  • extract EXE from downloaded archive;
  • and run it. If the utility runs successfully, it will output two lines with Move [old location] to [new location].

InterBase XE3 Developer Edition Accompanies Some Editions of Appmethod

This note pertains to users who have both an earlier version of Appmethod (1.13 or 1.14) and Appmethod 1.15 installed on the same machine.

Appmethod 1.13, 1.14, and 1.15 all include InterBase XE3 Developer Edition. Each license suite for Appmethod includes a license for InterBase XE3 Developer Edition as well. Since all these Appmethod license suites are visible system-wide, only one license of InterBase XE3 Developer Edition can be used at any time.

If you happen to be running the "InterBase XE3 Developer Edition" that came with an earlier Appmethod version, you will not be able to start a simultaneous "developer_ibxe3" instance of InterBase XE3 Developer Edition that comes with Appmethod 1.15. If you try to start this, you will receive an error dialog stating "InterBase licensing error". Further inspection of interbase.log from your "developer_ibxe3" instance will show "Registration file error: License is in use by another instance of InterBase".

Workaround for InterBase XE3 Licensing Errors

  1. Stop your "gds_db" or other named InterBase instance, as the case might be, from your Appmethod 1.13 or 1.14 install. If you have set up this instance as a Windows Service, please disable it in the system Service Control Panel also.
  2. Restart your Appmethod installed copy of InterBase XE3 "developer_ibxe3" instance. It will now launch successfully with the proper license.

The above mentioned earlier Appmethod version, and applications built using it, can also work with the updated InterBase XE3 Developer Edition installed with Appmethod 1.15. Have your Appmethod 1.13 or 1.14 IDE tools and applications connect to your database via TCP loopback to this InterBase instance. For example:


In the Appmethod IDE, you might also want to select Tools > Options > Environment Options > Environment Variables and add the following new "User overrides" entries for making local client connections.

  • Variable: IB_Protocol
    • Value: developer_ibxe3
  • Variable: InterBase
    • Value: C:\Program Files (x86)\Embarcadero\Studio\15.0\InterBaseXE3

Help Notes

Location of Installed Help

By default, the help files are installed at C:\Program Files (x86)\Embarcadero\Studio\15.0\Help\Doc.

Microsoft Document Explorer 2008 (DExplore.exe)

DExplore is required in order to view the Object Pascal and Appmethod C++ locally installed documentation. If you do not have Microsoft Document Explorer 2008 installed, it will be installed as part of the Help System Install.

  • It is a known issue that a pre-release version of the license for Microsoft Document Explorer XE is displayed.
  • If you receive an access violation when you press F1 in the IDE, it is possible that an incompatible version of DExplore.exe has been installed. To verify the version, run DExplore.exe standalone, check the Help | About box: If it says QFE, a quick fix has been installed by either Visual Studio 2008 or Prism. To fix this problem, go to the Control Panel and run a Repair operation on the Object Pascal and Appmethod C++ 1.15 Help System.


The Microsoft Windows Platform SDK help can be installed by choice with the product help. The help installer runs inside the product installer. You can choose to install the MS SDK Help when you install the help by setting the MS SDK Help item on the Select Features page of the Help installer to Will be installed on local hard drive. For more information, see the Installation Notes for Appmethod 1.14 file.

See Also