View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006665 | JEDI VCL | 02 Installation | public | 2019-03-03 10:05 | 2020-05-18 22:38 |
| Reporter | mh | Assigned To | obones | ||
| Priority | normal | Severity | block | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | Daily / GIT | ||||
| Target Version | Fixed in Version | Daily / GIT | |||
| Summary | 0006665: 10.3 Rio Update 1: Installer fails to compile JvAppIniStorage.pas | ||||
| Description | Installer fails to compile the JvAppIniStorage.pas file as Rio made some changes to TMemIniFile JvAppIniStorage.pas needs to adapt to. The reason is, that JvAppIniStorage.pas accesses the non public/protected FSection field from TMemIniFile via class helper which is no longer present in Rio. At least between XE8 and Rio 10.3 Update 1 there was a change in TMemIniFile where the code of JVCL has not been completely adapted to. The change was, that TMemIniFile is now based on TDictionary and the FSection StringList used in the old MemIni code is no longer there. Unfortunately JVCL has several places where it wants to access FSection. | ||||
| Tags | No tags attached. | ||||
|
|
Further investigation leads me to the suspiccion that the code path around line 251 which is for Rio and newer makes not much sense. It introduces a ClassHelper which introduces a FSections TStringList field, but this ins nowhere created nor freed and later on it is being accessed. Shouldn't that code work with the FEsctions dictionary from TMemIniFile? Another question: the original newsgroup poster's report pointed to line 251 which is in the pre Rio code path. If I'm not mistaken he talked about a Rio x64 isntallation. Why is the 64 bit compiler stepping into this path? Is there an issue with the RTL330_UP define in the 64 bit compiler? |
|
|
Ok, looking at it again (after being pointed out that I didn't read it right the first time) I found out that this part of the code is for versions from D2009 to Tokyo, but not for Rio. But this now leads to the question why the error messages posted by the original reporter of this in the JVCL newsgroup point to line 251 which is inside this block (at least in the JVCL version available via GetIt directly after installing Rio 10.3 Update 1)? Here's the relevant excerpt from the original report from the newsgroup: "[Compiling: JvCore260.bpl] Embarcadero Delphi for Win64 compiler version 33.0 Copyright (c) 1983,2017 Embarcadero Technologies, Inc. C:\ProgramData\Jvcl 201902Git\jvcl\run\JvAppIniStorage.pas(251) Erreur: E2003 Identificateur non déclaré : 'IndexOf' C:\ProgramData\Jvcl 201902Git\jvcl\run\JvAppIniStorage.pas(251) Avertissement: W1023 Comparaison de types signés et non signés - opérandes élargis C:\ProgramData\Jvcl 201902Git\jvcl\run\JvAppIniStorage.pas(260) Erreur: E2010 Types incompatibles : 'TStringList' et 'TMemIniFile.TSections' JvCore.dpk(2501) Fatale: F2063 Impossible de compiler l'unité utilisée 'JvAppIniStorage.pas' " |
|
|
The interesting question for me is, where is this error coming from? I'm compiling the current release without any problems with latest Rio Relase. |
|
|
Same problem for me (+1 another one). I'm also using a french version of Rio 10.3 update 1 [dcc32 Erreur] JvAppIniStorage.pas(251): E2003 Identificateur non déclaré : 'IndexOf' [dcc32 Erreur] JvTimerList.pas(595): E2003 Identificateur non déclaré : 'cnAdded' Looks like a problem with RTL330_UP define |
|
|
I managed to do a clean manual install from GitHub. But no success with Delphi GetIt utility. |
|
|
Ok, if you could install by fetching the verasion from Github,but not the one delivered via GetIt my question would be: what's the difference between those two? |
|
|
RTL330_UP wasn't defined when I installed with GetIt. Probably a path issue with jedi.inc |
|
|
This is now working fine with the content of the GIT repository, provided one also updates the submodules |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-03-03 10:05 | mh | New Issue | |
| 2019-03-03 15:18 | mh | Note Added: 0021611 | |
| 2019-03-04 22:49 | mh | Note Added: 0021613 | |
| 2019-04-14 13:13 | jfudickar | Note Added: 0021695 | |
| 2019-04-20 17:52 | DidierL | Note Added: 0021723 | |
| 2019-04-22 23:33 | DidierL | Note Added: 0021728 | |
| 2019-04-23 20:37 | mh | Note Added: 0021730 | |
| 2019-04-23 22:55 | DidierL | Note Added: 0021731 | |
| 2019-04-27 15:44 | jfudickar | Relationship added | has duplicate 0006655 |
| 2020-05-18 22:38 | obones | Assigned To | => obones |
| 2020-05-18 22:38 | obones | Status | new => resolved |
| 2020-05-18 22:38 | obones | Resolution | open => fixed |
| 2020-05-18 22:38 | obones | Fixed in Version | => Daily / GIT |
| 2020-05-18 22:38 | obones | Note Added: 0021876 |
