The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

    Mastodon

  • Twitter Updates

  • My Flickr Stream

    20140508-Delphi-2007--Project-Options--Cannot-Edit-Application-Title-HelpFile-Icon-Theming20140430-Fiddler-Filter-Actions-Button-Run-Filterset-now20140424-VMware-Fusion-6.0.3.-no-reclaimable
    More Photos

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,839 other subscribers

Archive for the ‘Delphi’ Category

« Previous Entries
Next Entries »

Delphi: When porting really old code from versions that did not have .dproj files, watch your .dfg and .dof files

Posted by jpluimers on 2021/06/10

I have been bitten by this a few times too much, so time to write it down:

When porting old Delphi code from the Delphi 7 and older era, the options were stored .dof (options) and .cfg (configuration) files.

More modern Delphi versions try to translate these files when generating the .dproj file, in a similar way as they try to upgrade older .dproj files to newer formats.

Many things can go wrong, including these ones I have bumped into multiple times:

  • DCC_DebugInformation having a 0 or false value, but not handling these values correctly (I remember problems around the Delphi XE5 era with this: When the Delphi XE5 commandline compiler fails with error F1026: File not found: ‘False.dpr’)
  • DCC_OutputDependencies not being adhered to (no .d file is being emitted by the compiler), though for the .drc files, DCC_OutputDRCFile works fine)
  • DCC_DebugInformation having a 1 value (Limited Debug information) instead of being absent (Debug information)
  • DCC_SymbolReferenceInfo having a 1 value (Definitions Only) instead of being absent (Reference info)

–jeroen

Posted in Delphi, Development, Software Development | 1 Comment »

Delphi: .dproj TargetedPlatforms bit flags in main PropertyGroup, and Platform values in other elements/attributes

Posted by jpluimers on 2021/06/09

For cleanup of .dproj files, I want to know the bit flags that TargetPlatforms can have.

TL;DR: .dproj content management in Delphi is a mess

For future reference empiric values for the flags that build the TargetedPlatforms (not to be confused with PlatformTargets) element content in the main PropertyGroup of a .dproj file in a table.

This might help creating an XSD for a .dproj file (Source: Reminder to self: make a start for an XSD that validates Delphi dproj files).

Absent cells means I have no idea if the values are relevant or what they could be.

Input for those is more than welcome.

Bit# TargetedPlatforms bit flag value Platform and $(Platform)value Meaning (dropdown value of “Select Platform” dialog)
0 1 Win32 32-bit Windows
1 2 Win64 64-bit Windows
2 4
3 8
4 16
5 32
6 64
7 128
8 256
9 512
10 1024 iOSDevice64 iOS Device 64-bit
11 2048
12 4096

($Platform) values still to cover:

  • Android
  • Linux64
  • OSX32
  • iOSDevice32
  • iOSSimulator

There is only one place for TargetedPlatforms in the .dproj file: at the XPath /Project/PropertyGroup/TargetedPlatforms.

For getting the XPath, I used Notepad++ as described in my earlier blog post Getting the path of an XML node in your code editor.

It has the combined flags, so:

  • 3 means Win32 and Win64 are enabled
  • 1025 means Win32 and iOSDevice64 are enabled

The Platform value (and thus $(Platform) value) is the one used in for example these elements or attributes:

  • /Project/PropertyGroup/Platform as currently selected platform
  • /Project/PropertyGroup/@Condition as selectivity expression, for instance
    •  <PropertyGroup Condition="('$(Platform)'=='Win64' and '$(Cfg_1)'=='true') or '$(Cfg_1_Win64)'!=''">
    • <PropertyGroup Condition="('$(Platform)'=='Win64' and '$(Base)'=='true') or '$(Base_Win64)'!=''">
  • /Project/ProjectExtensions/BorlandProject/Platforms/Platform (all having for the value property with the Platform value) having a content of either True or False.
    • This allows a .dproj file to contain information for platforms that are not visible yet.

The actual values of Platform also play a role in these places:

  • /Project/PropertyGroup/Base_Win64 containing the base settings for the Win64 platform so they can be derived for the Debug or Release builds.
  • /Project/PropertyGroup/@Condition for instance <PropertyGroup Condition="'$(Base_Win64)'!=''">
  • /Project/ProjectExtensions/BorlandProject/Deployment/DeployFile/Platform/@Name for instance <Platform Name="iOSSimulator">

Even worse: there are unneeded  nodes present for bits in TargetPlatforms and /Project/ProjectExtensions/BorlandProject/Platforms/Platform being absent or having a content False for /Project/ProjectExtensions/BorlandProject/Platforms/Platform/@value other than the enabled bits in TargetPlatforms, for instance:

  • nodes matched by /Project/ProjectExtensions/BorlandProject/Deployment/DeployFile/Platform
  • nodes matched by /Project/ProjectExtensions/BorlandProject/Deployment/ProjectRoot/@Platform
  • nodes matched by /Project/ProjectExtensions/BorlandProject/Deployment/DeployClass/Platform/@Name (and the parent DeployClass subtrees)
  • nodes matched by /Project/ProjectExtensions/BorlandProject/Platforms/Platform@value

Some examples of superfluous nodes when TargetPlarforms has a value of 1 (corresponding to Platform having a value of Win32:

<ProjectRoot Platform="Android" Name="$(PROJECTNAME)"/>
<ProjectRoot Platform="Linux64" Name="$(PROJECTNAME)"/>
<ProjectRoot Platform="OSX32" Name="$(PROJECTNAME).app"/>
<ProjectRoot Platform="Win32" Name="$(PROJECTNAME)"/>
<ProjectRoot Platform="Win64" Name="$(PROJECTNAME)"/>
<ProjectRoot Platform="iOSDevice32" Name="$(PROJECTNAME).app"/>
<ProjectRoot Platform="iOSDevice64" Name="$(PROJECTNAME).app"/>
<ProjectRoot Platform="iOSSimulator" Name="$(PROJECTNAME).app"/>

Also, non relevant platforms are included in this node:

<Platforms>
    <Platform value="Win32">True</Platform>
    <Platform value="Win64">False</Platform>
</Platforms>

The Deployment section is even worse; see for instance [WayBack] delphi – How manage or clean deploy section in dproj files? – Stack Overflow.

–jeroen

Posted in Conference Topics, Conferences, Delphi, Development, Event, Software Development | 1 Comment »

Delphi: some notes on HModule while tracking down an access violation in TRegGroups.UnregisterModuleClasses

Posted by jpluimers on 2021/06/08

Too bad the whole mechanism involving TRegGroups.UnregisterModuleClasses is not documented anywhere

It is the underlying storage to support TClassFinder, which was introduced in Delphi 6, documented on-line in Delphi 2007, documented slightly in Delphi 2009, and since Delphi 2010 only one line of documentation was added (including the unchanged “instatiated”):

  • Delphi 2007: [WayBack] TClassFinder Class

    This is class Classes.TClassFinder.

  • Delphi 2009:[WayBack] TClassFinder Class

    The TClassFinder allows the list of registered persistent classes to be retrieved. Objects instatiated from persistent classes are those that can be stored (serialised) beyond the operation of the current application.

  • Delphi 2010:[WayBack] Classes.TClassFinder – RAD Studio VCL Reference

    TClassFinder allows registered persistent classes to be retrieved.

    The TClassFinder allows the list of registered persistent classes to be retrieved. Objects instatiated from persistent classes are those that can be stored (serialised) beyond the operation of the current application.

Back to TRegGroups.UnregisterModuleClasses: it takes a HMODULE parameter and ultimately gets called through the (since Delphi 2007) on-line documented [WayBack] Classes.UnRegisterModuleClasses Function

procedure UnRegisterModuleClasses(Module: HMODULE);

Call UnRegisterModuleClasses to unregister all object classes that were registered by the module with the handle specified by the Module parameter. When a class is unregistered, it can’t be loaded or saved by the component streaming system.

After unregistering a class, its name can be reused to register another object class.

To get more context about the access violation, I used both the stack trace and a debugging watch for GetModuleName(Module) (using the [WayBack] SysUtils.GetModuleName Function).

In order to see which classes were registered by what module, I set a breakpoint at in TRegGroup.AddClass (which can be called through various code paths):

procedure TRegGroup.AddClass(AClass: TPersistentClass);
begin
  FGroupClasses.Add(AClass);
end;

HModule

That gave me the class, but I also needed the HModule for a class, so I did a windows get module of currently executing code – Google Search, giving me these links, all C/C++ related:

Here you already see some confusion: there is HINSTANCE and HMODULE. That’s a historic thing, as described by Raymond Chen in [WayBack] What is the difference between HINSTANCE and HMODULE? | The Old New Thing:

They mean the same thing today, but at one time they were quite different.
It all comes from 16-bit Windows.
In those days, a “module” represented a file on disk that had been loaded into memory, and the module “handle” was a handle to a data structure that described the parts of the file, where they come from, and where they had been loaded into memory (if at all). On the other hand an “instance” represented a “set of variables”.
One analogy that might (or might not) make sense is that a “module” is like the code for a C++ class – it describes how to construct an object, it implements the methods, it describes how the objects of the class behave. On the other hand, an “instance” is like a C++ object that belongs to that class – it describes the state of a particular instance of that object.
In C# terms, a “module” is like a “type” and an instance is like an “object”. (Except that modules don’t have things like “static members”, but it was a weak analogy anyway.)

GetModuleName

Searching for delphi “__ImageBase” – Google Search then got me [WayBack] c++ – Get DLL path at runtime – Stack Overflow with a nice Delphi related answer by [WayBack] Ian Boyd:

For Delphi users:

SysUtils.GetModuleName(hInstance);              //Works; hInstance is a special global variable
SysUtils.GetModuleName(0);                      //Fails; returns the name of the host exe process
SysUtils.GetModuleName(GetModuleFilename(nil)); //Fails; returns the name of the host exe process

In case your Delphi doesn’t have SysUtils.GetModuleName, it is declared as:

...

This reassured my use of [WayBack] SysUtils.GetModuleName code was OK:

function GetModuleName(Module: HMODULE): string; 
var
  ModName: array[0..MAX_PATH] of Char; 
begin
  SetString(Result, ModName, GetModuleFileName(Module, ModName, Length(ModName))); 
end;

HInstance in Delphi

The example from Ian Boyd also brought back memories from long ago about the [WayBack] HInstance Variable – Delphi in a Nutshell [Book]:

Read the rest of this entry »

Posted in Conference Topics, Conferences, Delphi, Development, Event, History, Software Development | Leave a Comment »

Who maintains GExperts · GitHub?

Posted by jpluimers on 2021/06/03

I wnder who maintains [WayBack] GExperts · GitHub:

GExperts has 4 repositories available. Follow their code on GitHub.

It has not been updated for about 5 years, but contains some important bits.

–jeroen

 

Posted in Delphi, Development, GExperts, Software Development | 1 Comment »

Delphi: Passing build variables to batch files; I think the easiest is to use environment variables

Posted by jpluimers on 2021/06/02

A long time ago, I wrote about Delphi prebuild/prelink/postbuild events.

In practice, especially that you cannot inherit build events, then add new ones (), it is convenient to put all you need in a script, for instance a batch file.

Passing parameters to that script, then in my experience, is easiest to do as environment variables.

That way you can do this in a script:

> %temp%\build.txt echo ~dp0=%~dp0
>> %temp%\build.txt echo $(BDS)=%BDS%
>> %temp%\build.txt echo $(INPUTDIR)=%INPUTDIR%
>> %temp%\build.txt echo $(PROJECTDIR)=%PROJECTDIR%
>> %temp%\build.txt echo $(OUTPUTDIR)=%OUTPUTDIR%
>> %temp%\build.txt echo $(Platform)=%Platform%

if "%OUTPUTDIR:~0,2%"==".." set OUTPUTDIR=%INPUTDIR%%OUTPUTDIR%
>> %temp%\build.txt echo $(OUTPUTDIR)=%OUTPUTDIR%

Passing the parameters and calling the script results in this build event contents:

set Platform=$(Platform)
set INPUTDIR=$(INPUTDIR)
set PROJECTDIR=$(PROJECTDIR)
set OUTPUTDIR=$(OUTPUTDIR)
call ..\post-build-event.bat

The IDE then shows this fragment in the project output:

Target PostBuildEvent:
    set Platform=Win32&&set INPUTDIR=D:\Versioned\TestRepostitory\Test Project With Spaces\&&set PROJECTDIR=D:\Versioned\TestRepostitory\Test Project With Spaces&&set OUTPUTDIR=..\EXE Output Directory With Spaces\&&call ..\post-build-event.bat

The above batch file also shows things:

  1. how to handle relative directories in the OUTPUTDIR build parameter: check if the first two characters are .. (trick via [WayBack] Check if Batch variable starts with “…” – Stack Overflow).
  2. spaces are handled fine without any need to double quote the set assignments
  3. build-event lines are concatenated using the && success operator
  4. Parameters INPUTDIR and OUTPUTDIR end with a backslash, but PROJECTDIR does not (Delphi prebuild/prelink/postbuild events explains more about the parameters).

Note:

  • environment variable BDS does not end in a backslash
  • expansion %~dp0 does end in a backslash

With this trick now you can copy BPL files for the right platform:

xcopy /y "%BDS%\Redist\%Platform%\rtl250.bpl" "%OUTPUTDIR%"

Note that the LibSuffix (with value 250 for Delphi 10.2 Tokyo) is not available as environment variable, nor build parameter. The environment variable ProductVersion however (with value 19.0 for Delphi 10.2 Tokyo) is. So technically, you could make a mapping.

–jeroen

Posted in Conference Topics, Conferences, Delphi, Development, Event, Software Development | Leave a Comment »

c++ – DLL Load Library – Error Code 126 – Stack Overflow: use Process Monitor, search for the first NAME NOT FOUND

Posted by jpluimers on 2021/06/01

In addition to [WayBack] c++ – DLL Load Library – Error Code 126 – Stack Overflow while debugging LoadLibrary error 126

Windows dll error 126 can have many root causes. The most useful methods I have found to debug this are:

  1. Use dependency walker to look for any obvious problems (which you have already done)
  2. Use the sysinternals utility [WayBack] Process Monitor – Windows Sysinternals | Microsoft Docs from Microsoft to trace all file access while your dll is trying to load. With this utility, you will see everything that that dll is trying to pull in and usually the problem can be determined from there.

Search for the first entry NAME NOT FOUND after your library is being loaded.

It indicates the module that cannot be found which indirectly causes error number 126 (ERROR_MOD_NOT_FOUND in [WayBack] System Error Codes (0-499) – Windows applications | Microsoft Docs ) in [WayBack] LoadLibrary:

 

ERROR_MOD_NOT_FOUND

126 (0x7E)

The specified module could not be found.

 

This is why I upvoted the very relevant comment:

… when I looked at the rows surrounding my dll being loaded I saw MSVCP140D.dll was giving a result of NAME NOT FOUND. Turns out the machine that couldn’t load my dll doesn’t have the ‘D’ version of MSVCP140.dll. Everything worked when I built my dll for release! – [WayBack] Pakman.

–jeroen

Posted in Delphi, Development, Software Development, Windows Development | Leave a Comment »

Devart ODAC product versions (Oracle Data Access Components History)

Posted by jpluimers on 2021/06/01

ODAC version history is confusing wheres [WayBack] Oracle Data Access Components – FAQ talks about version 6.00, [WayBack] Oracle Data Access Components History talks about version 10.x.y.

The history page is correct.

–jeroen

Posted in Delphi, Development, Software Development | Leave a Comment »

Porting old code: Delphi compiler error E2064 Left side cannot be assigned to

Posted by jpluimers on 2021/05/27

Quoting this in full because it nicely illustrated the introduction of an intermediate variable that cannot be assigned to a second time after initial setup by the with statement: [WayBack] Embarcadero Newsgroup Archive :: embarcadero.public.delphi.ide :: Re: Delphi 2010 Compile error E2064 Left side cannot be assigned to.

Subject: Re: Delphi 2010 Compile error E2064 Left side cannot be assigned to
Posted by: Uwe Schuster (jediv…@bitcommander.de)
Date: Sat, 10 Oct 2009

Finn Tolderlund wrote:

> I get this error in Delphi 2010 with the code below:
> But if I remove the () from the line, it compiles and executes ok.
> Is it a bug in the compiler?
> …
>  with (Pal.palPalEntry[i]) do  // Compile error: E2064 Left side cannot be assigned to
>  with Pal.palPalEntry[i] do  // Works fine

This is no bug, because the parenthesis generates an intermediate
non-addressable value and D2010 does not longer allow write access to intermediate values with “with”.

—
Uwe

This also might explain Delphi 10.2 Tokyo introduced a “with” warning: for most “with” statements, W1048 is raised ([RSP-17326] with statements generate W1048 unsafe typecast warning – Embarcadero Technologies), assuming that the intermediate is a pointer variable.

–jeroen

Posted in Delphi, Development, Software Development | Leave a Comment »

msbuild build events can inherit, but not add in addition to inherited build events (so projects in Visual Studio, Delphi and others cannot do that either)

Posted by jpluimers on 2021/05/26

Bummer: I tried to inherit the build events from a base configuration, then add some extra steps for some of the inheriting configurations.

Those configurations just executed the extra steps, not the inherited steps.

This affects Visual Studio, Delphi and any other tool based on msbuild, as this is an ms-build thing:

–jeroen

Posted in .NET, Continuous Integration, Delphi, Development, msbuild, Software Development, Visual Studio and tools | Leave a Comment »

Figure out access violation in Dsmtoolwindow.GetPreferences

Posted by jpluimers on 2021/05/26

Access violation when loading the Delphi IDE

Got the below error on Delphi 10.2 Tokyo with ODAC trial from DevArt at Delphi startup time (Error: Access violation at address 188F3528 in module 'DataSetManager250.bpl'. Read of address 00000000.).

My guess it is some configuration prerequisite which – when not existing – is handled very ungracefully.

This might have to do with my installation being a non-administrator Delphi user, but the ODAC installation requiring UAC elevation to administrative level.

In short this means the installing user is different from the user that runs Delphi.

Related (indicating it was fixed years ago, but apparently isn’t) via dsmtoolwindow.getpreferences – Google Search:

Workaround is to unregister the DataSetManager250.bpl package, though I have to figure out what functionality that disables.

[188F3528]{DataSetManager250.bpl} Dsmtoolwindow.GetPreferences + $18
[23CA524D]{Jcl240.bpl  } Jclhookexcept. + $0
[50060B13]{rtl250.bpl  } System.@HandleAnyException (Line 19991, "System.pas" + 13) + $0
[211B3A05]{designide250.bpl} DockForm.TDockableForm.FormCreate (Line 258, "DockForm.pas" + 11) + $1B
[188F2DEA]{DataSetManager250.bpl} Dsmtoolwindow.TDsmToolWindow.FormCreate + $4E
[50C06BC1]{vcl250.bpl  } Vcl.Forms.TCustomForm.DoCreate (Line 3788, "Vcl.Forms.pas" + 3) + $C
[50C067DD]{vcl250.bpl  } Vcl.Forms.TCustomForm.AfterConstruction (Line 3671, "Vcl.Forms.pas" + 1) + $D
[50060039]{rtl250.bpl  } System.@AfterConstruction (Line 18301, "System.pas" + 2) + $5
[188EBE9B]{DataSetManager250.bpl} Dsmtoolwindow.TDsmToolWindow + $43B
[188EA93D]{DataSetManager250.bpl} Dsmtoolwindow.TDsmToolWindow.CreateForm + $19
[188F7C81]{DataSetManager250.bpl} Dsmexpert.initialization + $31
[50061276]{rtl250.bpl  } System.InitUnits (Line 22833, "System.pas" + 21) + $0
[500612E6]{rtl250.bpl  } System.@PackageLoad (Line 22861, "System.pas" + 8) + $0
[188A1A09]{DataSetManager250.bpl} __dbk_fcall_wrapper + $195
[188F6DA1]{DataSetManager250.bpl} Initialize + $5
[500A0377]{rtl250.bpl  } System.SysUtils.InitializePackage (Line 25779, "System.SysUtils.pas" + 4) + $0
[500A04D1]{rtl250.bpl  } System.SysUtils.LoadPackage (Line 25830, "System.SysUtils.pas" + 18) + $5
[21E1AFAF]{delphicoreide250.bpl} PasCppPakMgr.TIDEDesignPackage.ClearModules (Line 2189, "PasCppPakMgr.pas" + 14) + $10
[204E9A94]{coreide250.bpl} PakLoad.TPackage.DoLoadPackage (Line 146, "PakLoad.pas" + 0) + $8
[204E9C09]{coreide250.bpl} PakLoad.TPackage.Load (Line 220, "PakLoad.pas" + 7) + $7
[204EC425]{coreide250.bpl} PakMgr.TDesignPackage.Load (Line 591, "PakMgr.pas" + 2) + $2
[21E1B2CB]{delphicoreide250.bpl} PasCppPakMgr.TIDEDesignPackage.Load (Line 2292, "PasCppPakMgr.pas" + 4) + $3
[50060039]{rtl250.bpl  } System.@AfterConstruction (Line 18301, "System.pas" + 2) + $5
[21E1B0DF]{delphicoreide250.bpl} PasCppPakMgr.TIDEDesignPackage.DelayLoad (Line 2217, "PasCppPakMgr.pas" + 11) + $4
[21E1572A]{delphicoreide250.bpl} PasCppPakMgr.LoadDesignPackage (Line 463, "PasCppPakMgr.pas" + 10) + $5
[0B6A0F84]{IDEFixPack.dll} SplashProgress2005p.HookedLoadDesignPackage (Line 277, "SplashProgress2005p.pas" + 3) + $3
[21E15A33]{delphicoreide250.bpl} PasCppPakMgr.LoadProjectPackages (Line 534, "PasCppPakMgr.pas" + 52) + $11
[21F20DBF]{delphicoreide250.bpl} BasePasProjOpts.TProjOptsManager.DoLoadPackages (Line 1604, "BasePasProjOpts.pas" + 22) + $6
[21F21BB4]{delphicoreide250.bpl} BasePasProjOpts.TProjOptsManager.LoadPackages (Line 1839, "BasePasProjOpts.pas" + 0) + $0
[21F22BD5]{delphicoreide250.bpl} BasePasProjOpts.TProjectOptions.LoadPackages (Line 2419, "BasePasProjOpts.pas" + 0) + $5
[22585BF3]{delphide250.bpl} DelphiProject.TDelphiProjectCreationTrait.LoadDefaultLibraries (Line 256, "DelphiProject.pas" + 1) + $1F
[2058A109]{coreide250.bpl} ProjectGroup.TDefaultProjectWrapper.LoadDefaultLibraries (Line 3544, "ProjectGroup.pas" + 5) + $31
[206DB2B9]{coreide250.bpl} Desktop.LoadDefaultDesktopState (Line 966, "Desktop.pas" + 3) + $9
[206DC0D5]{coreide250.bpl} Desktop.LoadDesktop (Line 1223, "Desktop.pas" + 73) + $0
[0049FBA8]{bds.exe     } AppMain.PostCreateInit (Line 2154, "AppMain.pas" + 57) + $0
[004A00B6]{bds.exe     } AppMain.TAppBuilder.CMPostCreateInit (Line 2257, "AppMain.pas" + 4) + $1
[50AC4C16]{vcl250.bpl  } Vcl.Controls.TControl.WndProc (Line 7326, "Vcl.Controls.pas" + 91) + $6
[50C110C3]{vcl250.bpl  } Vcl.Forms.TApplication.WndProc (Line 10270, "Vcl.Forms.pas" + 194) + $1
[50AC97FB]{vcl250.bpl  } Vcl.Controls.TWinControl.WndProc (Line 10197, "Vcl.Controls.pas" + 166) + $6
[50C080B5]{vcl250.bpl  } Vcl.Forms.TCustomForm.WndProc (Line 4546, "Vcl.Forms.pas" + 209) + $5
[50AC8DC8]{vcl250.bpl  } Vcl.Controls.TWinControl.MainWndProc (Line 9896, "Vcl.Controls.pas" + 3) + $6
[5016EBC4]{rtl250.bpl  } System.Classes.StdWndProc (Line 17406, "System.Classes.pas" + 9) + $2
[50C11A6F]{vcl250.bpl  } Vcl.Forms.TApplication.ProcessMessage (Line 10613, "Vcl.Forms.pas" + 23) + $1
[50C11AB2]{vcl250.bpl  } Vcl.Forms.TApplication.HandleMessage (Line 10643, "Vcl.Forms.pas" + 1) + $4
[50C11DE5]{vcl250.bpl  } Vcl.Forms.TApplication.Run (Line 10781, "Vcl.Forms.pas" + 26) + $3
[005088E2]{bds.exe     } bds.bds (Line 212, "" + 7) + $7

Solved the access violation

Notes:

  • %APPDATA% points to %USERPROFILE%\AppData\Roaming (where usually %USERPROFILE% is on the %HOMEDRIVE%)

Fix script (the double backslash \\ is needed, otherwise the final double quote " becomes part of the path name):

setlocal
:: 19.0 is the version for Delphi 10.2 Tokyo 
set ProductVersion=19.0
reg add "HKEY_CURRENT_USER\Software\Devart\DataSetManager\BDS\%ProductVersion%" /v "ConfigFilePath" /f /t REG_SZ /d "%APPDATA%\Embarcadero\BDS\%ProductVersion%\\"
endlocal

This allows for an XML file named DataSetManager.cfg to be created in the ConfigFilePath directory.

Even though Process Monitor will show access to the below keys, there is no need to add any values there:

  • KEY_CURRENT_USER\Software\Devart\DBMonitor
  • KEY_CURRENT_USER\SOFTWARE\Devart\ODAC
  • HKLM\Software\WOW6432Node\Devart\ODAC
  • HKLM\Software\WOW6432Node\Devart\Odac

Deploy enough BPLs

Another thing when running ODAC trial and licensed applications

---------------------------
ODAC
---------------------------
%1 is not a valid Win32 application
ODAC Trial version needs additional "bpl" files to be present on the user PC.
If you build your project without run-time packages you need:
  dac250.bpl
  odac250.bpl
---------------------------
OK   
---------------------------

This message is incomplete; what it should say is that any BPL dependencies must be deployed. One way to find out about those is to use I wanted to know the loaded DLLs in a process like Process Explorer shows, but from the console: Sysinternals ListDLLs to the rescue.

Another way is to use TDUMP (see [WayBack] TDUMP.EXE, the File Dumping Utility) and search for the import tables. I did just that for the 10.2 trial; below is the full list.

There is way better documentation at Devart ODAC Deployment: Deploying Windows applications built without run-time packages which fails to properly archive in the WayBack machine (it gets into a redirect loop) so I quote it in full:

Deploying Windows applications built without run-time packages

You do not need to deploy any files with ODAC-based applications built without run-time packages, provided you are using a registered version of ODAC.

You can check your application does not require run-time packages by making sure the “Build with runtime packages” check box is not selected in the Project Options dialog box.

Trial Limitation Warning

If you are evaluating deploying Windows applications with ODAC Trial Edition, you will need to deploy the following DAC BPL files:

dacXX.bpl always
odacXX.bpl always

and their dependencies (required IDE BPL files) with your application, even if it is built without run-time packages:

rtlXX.bpl always
dbrtlXX.bpl always
vcldbXXX.bpl always

Deploying Windows applications built with run-time packages

You can set your application to be built with run-time packages by selecting the “Build with runtime packages” check box in the Project Options dialog box before compiling your application.

In this case, you will also need to deploy the following BPL files with your Windows application:

dacXX.bpl always
odacXX.bpl always
dacvclXX.bpl if your application uses the OdacVcl unit
odacvclXX.bpl if your application uses the OdacVcl unit
crcontrolsXX.bpl if your application uses the CRDBGrid component

From those posts and the below full list, you also need to deploy the bold dependencies:

  • dac250.bpl
    • rtl250.bpl
    • dbrtl250.bpl
  • odac250.bpl
    • rtl250.bpl
    • dbrtl250.bpl
    • dac250.bpl

Enabling your projects to use ODAC packages

To get around errors like "E2202 Required package 'odac' not found", you need to ensure the correct .dcp files for ODAC are referenced.

Unlike Delphi, the ODAC .dcp files contain a version number, so in your required packages list, ensure you add them not like rtl;dbrtl, but like dac250;odac250.

List of various ODAC BPL dependencies

dac250.bpl
Imports from kernel32.dll
Imports from rtl250.bpl
Imports from wsock32.dll
Imports from dbrtl250.bpl
Imports from ole32.dll
Imports from user32.dll

dacfmx250.bpl
Imports from kernel32.dll
Imports from rtl250.bpl
Imports from dbrtl250.bpl
Imports from user32.dll
Imports from fmx250.bpl
Imports from dac250.bpl

dacvcl250.bpl
Imports from kernel32.dll
Imports from rtl250.bpl
Imports from dbrtl250.bpl
Imports from user32.dll
Imports from dac250.bpl
Imports from vcl250.bpl

dcldac250.bpl
Imports from vclactnband250.bpl
Imports from wininet.dll
Imports from shell32.dll
Imports from user32.dll
Imports from version.dll
Imports from oleaut32.dll
Imports from dac250.bpl
Imports from dacvcl250.bpl
Imports from vcldb250.bpl
Imports from dcldb250.bpl
Imports from xmlrtl250.bpl
Imports from kernel32.dll
Imports from rtl250.bpl
Imports from designide250.bpl
Imports from ole32.dll
Imports from dbrtl250.bpl
Imports from gdi32.dll
Imports from vcl250.bpl

odac250.bpl
Imports from kernel32.dll
Imports from rtl250.bpl
Imports from dbrtl250.bpl
Imports from version.dll
Imports from user32.dll
Imports from dac250.bpl
Imports from advapi32.dll

odacvcl250.bpl
Imports from kernel32.dll
Imports from odac250.bpl
Imports from rtl250.bpl
Imports from dbrtl250.bpl
Imports from dac250.bpl
Imports from dacvcl250.bpl
Imports from vcl250.bpl

dclodac250.bpl
Imports from vclactnband250.bpl
Imports from odac250.bpl
Imports from dcldac250.bpl
Imports from odacvcl250.bpl
Imports from shell32.dll
Imports from user32.dll
Imports from dac250.bpl
Imports from dcldb250.bpl
Imports from vcldb250.bpl
Imports from dacvcl250.bpl
Imports from vclimg250.bpl
Imports from kernel32.dll
Imports from xmlrtl250.bpl
Imports from rtl250.bpl
Imports from designide250.bpl
Imports from dbrtl250.bpl
Imports from vcl250.bpl

odacfmx250.bpl
Imports from kernel32.dll
Imports from odac250.bpl
Imports from rtl250.bpl
Imports from dacfmx250.bpl
Imports from dbrtl250.bpl
Imports from fmx250.bpl
Imports from dac250.bpl

dclodacfmx250.bpl
Imports from kernel32.dll
Imports from odac250.bpl
Imports from odacfmx250.bpl
Imports from rtl250.bpl
Imports from dacfmx250.bpl
Imports from dbrtl250.bpl
Imports from fmx250.bpl
Imports from dac250.bpl

oraprov250.bpl
Imports from kernel32.dll
Imports from odac250.bpl
Imports from dsnap250.bpl
Imports from rtl250.bpl
Imports from dbrtl250.bpl
Imports from dac250.bpl

dcloraprov250.bpl
Imports from kernel32.dll
Imports from odac250.bpl
Imports from dsnap250.bpl
Imports from rtl250.bpl
Imports from dbrtl250.bpl
Imports from oraprov250.bpl
Imports from dac250.bpl

datasetmanager250.bpl
Imports from vclactnband250.bpl
Imports from dcldac250.bpl
Imports from comctl32.dll
Imports from user32.dll
Imports from dac250.bpl
Imports from vclx250.bpl
Imports from dacvcl250.bpl
Imports from dcldb250.bpl
Imports from vcldb250.bpl
Imports from kernel32.dll
Imports from xmlrtl250.bpl
Imports from rtl250.bpl
Imports from designide250.bpl
Imports from dbrtl250.bpl
Imports from gdi32.dll
Imports from vcl250.bpl

crcontrols250.bpl
Imports from kernel32.dll
Imports from rtl250.bpl
Imports from dbrtl250.bpl
Imports from user32.dll
Imports from dac250.bpl
Imports from vcldb250.bpl
Imports from vcl250.bpl
Imports from gdi32.dll

dclcrcontrols250.bpl
Imports from kernel32.dll
Imports from rtl250.bpl
Imports from dbrtl250.bpl
Imports from crcontrols250.bpl
Imports from dac250.bpl
Imports from vcldb250.bpl
Imports from vcl250.bpl

oramigwizard250.dll
Imports from vclactnband250.bpl
Imports from odac250.bpl
Imports from odacvcl250.bpl
Imports from dcldac250.bpl
Imports from shell32.dll
Imports from user32.dll
Imports from dac250.bpl
Imports from vclx250.bpl
Imports from dcldb250.bpl
Imports from vcldb250.bpl
Imports from dacvcl250.bpl
Imports from vclimg250.bpl
Imports from kernel32.dll
Imports from xmlrtl250.bpl
Imports from dclodac250.bpl
Imports from rtl250.bpl
Imports from designide250.bpl
Imports from dbrtl250.bpl
Imports from vcl250.bpl

packagewizard250.dll
Imports from vclactnband250.bpl
Imports from odac250.bpl
Imports from odacvcl250.bpl
Imports from dcldac250.bpl
Imports from dac250.bpl
Imports from vclx250.bpl
Imports from dacvcl250.bpl
Imports from vcldb250.bpl
Imports from dcldb250.bpl
Imports from vclimg250.bpl
Imports from kernel32.dll
Imports from xmlrtl250.bpl
Imports from dclodac250.bpl
Imports from rtl250.bpl
Imports from designide250.bpl
Imports from dbrtl250.bpl
Imports from vcl250.bpl

–jeroen

Posted in Delphi, Delphi 10.2 Tokyo (Godzilla), Development, Software Development | Leave a Comment »

« Previous Entries
Next Entries »