Cirrus22

I'm running Delphi 11.3 CE. I have used the JvVCLVersionInfo component and confirmed with Windows>Properties>Details>File Version that the Version Info in my executable is stuck at the version that was put there in Delphi 10.3CE. In Project>Options>File Version I have include Version information in project set, see image( 0.9.3.X): here's what Windows is getting from the file (0.9.1.1346): I've also tried using different components to display the version info, they all agree and it's wrong. Anyone else having similar issues? Is there someplace else I need to set something? Thanks.......

@Rollo62Thanks again for the heads-up WRT ProjectMagician. Tried the ProjectMagician Tool (specifically Normalise and Clear Settings in Child Configurations>Version Info) and that does not seem to have done anything. The Version number in Project>Options>Application>Version Info is 0.9.3.14. The version info in Windows Explorer>File>Properties is 0.9.2.96. I have raised an issue with Embarcadero (RSP-42185) and have sent a .dproj file over for the support people to have a look at, but, and also, any other suggestions greatly appreciated. Kevin

I moved from D10.4.2 (IIRC) to the D11.3 CE. I have already posted about issues with File Version, but here's something that may be correct or not. This is a DLL. When I view the Project pane in the IDE, it only shows the project, it does not show the related (or any other) *.pas files. There seems no way I can make it show them. For the record, the PAS file is uDbXConnect.pas: And further, in GIT version control, it only shows the *.dproj, I cannot, within the IDE at least, add any other files (just as I cannot in IDE>Project. Previously I was using subversion (yes, I know not as good, but at least it worked and was simple). I cannot get subversion to work with 11.3 - that's another issue. Here's what I see in GIT Commit, only the dproj file. Note I can view all of the non-versioned files, but I cannot seem to get them to add to the GIT version control/repository. Am I supposed to be doing things with GIT outside the IDE, that kinda makes no sense if we are assuming this is Version Control with IDE integration. As noted, with subversion previously, it was relatively easy, this just doesn't seem to work (as I expected it to). Does anyone have a handle on what I should do to set this up correctly or can point me to appropriate documentation? Thanks......

@Rollo62 Hi, no not aware. I will definitely have a look, thanks for the link.

@Fr0sT.BrutalYes, definitely configured for release, and it's a 32 bit build. Wait, I see I have debug build clicked min the version info. Let me get rid of that. Nope that didn't make any difference to the size or getting the current version info.

Hi, This is probably lack of understanding. I cannot see where the debugger for GExperts is. But wherever it is it pops debug messages (only very occasionally) when I throw an error. For Example: This is simply a rasise Exception.create(........ I don't want this happening. How do I DISABLE (or later perhaps ENABLE) the GExperts debugger???? Thanks, kevin

As usual, prompt and precise explanation. Thank you for getting back to me. Cheers, Kevin

Hi, This may be normal behavior, but I'm at your download page which states ...Pick a version to download... I select the version for D10.4 GXRS 10.4_1....., but I get the latest version for D11 GXRS11_1....... downloaded. In fact, no matter what version I select to download, I always get GXRS 11_1..... version. Is that correct or should I get a version that has the name of the file I think I'm downloading? Thanks, Kevin

Hi, Thanks for getting back. Yes, it was strange that the filename being downloaded was always D11_..... but it did install and work correctly in Delphi 10.4 so all good. Probably, as you suggest, something happening with the name on download (it's standard Edge browser). Anyway, it's working that's the main thing. Thank you for you interest and assistance. Cheers, Kevin

Hi, Thanks for getting back. Here's the website (and the file I'm trying to download (note the 10.4 in the name): For clarity the URL is: GExperts 1.3.21 experimental twm 2022-04-09 – twm's blog (dummzeuch.de) and the filename to download is: GXRS10.4_1.3.21_experimental-twm_2022_04_09.exe The file that actually gets downloaded if I click the link is: GXRS11_1.3.21_experimental-twm_2022_04_09.exe (in fact if I click any link it downloads this file). Regardless, I ran this installation file ( GXRS11_1.3.21_experimental-twm_2022_04_09.exe) and (after an issue with paths and a previous installation) it installed correctly into my Delphi 10.4 application, so it's now working. I was (and still am a bit) confused when the website specifically references a version edition and I always get GXRS11_1.3.21....... downloaded. Obviously this is a single edition that contains the tweaks for all of the available versions of Delphi. I'm glad I figured it out, GExperts is a very nice addition to the normal Delphi IDE. Happy to close this as an issue, my lack of knowledge probably played a significant part in my confusion. Cheers, Kevin

Apologies, and maybe it's staring me in the face, but I cannot find it. The help file shows the headings, but there is no detail on the RHS of the page, it's blank, so that's of no use. This is what it looks like. Regardless, I just want to be able to limit the instances of the IDE running to 1. I'm using 10.4.2 Community edition. GExperts is installed. I've been all over it and cannot find where the checkbox is to limit the number of instances to 1. Again, apologies if it's obvious, just not obvious to me. Kevin

Hi, I have spent several days fighting my way through an install of JCL/JVCL. I'm using 10.4.2 CE. I have variously installed/uninstalled from GITHUB and GETIT. I'm now where I was several days ago in that (and the only version I installed was Win32). Now the installation all looks good. Successful completion messages, and paths all set. BUT when I do a Build of the first project I get this message: 'Your Delphi/BCB version is not supported by this JVCL version!' YET if I look at the inc file (where this message was generated jvcl.inc), it clearly is: {-----------------------------------------------------------------------------} {$IFDEF BCB21} {$IFDEF CPUX86} {$I jvcld21win32.inc} // same include file for BDS based C++ {$ENDIF CPUX86} {$IFDEF CPUX64} {$I jvcld21_x64.inc} {$ENDIF CPUX64} {$DEFINE JVCL_CONFIGURED} {$ENDIF BCB21} .... .... {$IFNDEF JVCL_CONFIGURED} {$IFDEF SUPPORTS_COMPILETIME_MESSAGES} {$MESSAGE FATAL 'Your Delphi/BCB version is not supported by this JVCL version!'} {$ELSE} 'Your Delphi/BCB version is not supported by this JVCL version!' {$ENDIF SUPPORTS_COMPILETIME_MESSAGES} {$ENDIF !JVCL_CONFIGURED} I am at a complete loss. Of course I could simply hardcode $DEFINE JVCL_CONFIGURED, but that addresses the symptom not the problem. Does anyone have any idea of how I might fix this. A simple install has so far taken several days. See below. This may not be the best way, but at least my software will now build and run and, with limited testing, as expected. I'll submit the topic for anyone elese that might have the same issues. UPDATE: I did simply set JVCL_CONFIGURED and the install progressed, again addressing the symptoms not the issue. There were a couple of other issue with the install, well some units anyway, where the symptoms were addressed: jvspeedbarsetupform.pas: //MaxHeight := PPIScale (self, MaxBtnListHeight); // Didn't like PPIScale so just set to a value I found in the code (I don't use jvspeedbar) MaxHeight := 186; jvpickdate.pas function CreateDateDialog(const DlgCaption: TCaption; MinDate: TDateTime; MaxDate: TDateTime): TJvSelectDateDlg; begin const cDefaultPixelsPerInch : Integer = 96; // Wasn't defined in this function so I defined it For completeness my update to Delphi SYDNEY 10.4 issue: And I don't know if this is at all JEDI Related, but got the error in ServiceManager.pas where a pointer type was incompatible, there were about 5 instances. The 'fix' was from the internet, don't know if there are any repercussions: The advice: If I change Services^ to Services, it does compile... still need to see if the function actually still works. // Change Services^ to Services //if not EnumServicesStatus(FManager, SERVICE_WIN32, SERVICE_ACTIVE or SERVICE_INACTIVE, // Services^,BytesNeeded, BytesNeeded,ServicesReturned,ResumeHandle) then Exit; if not EnumServicesStatus(FManager, SERVICE_WIN32, SERVICE_ACTIVE or SERVICE_INACTIVE, Services,BytesNeeded, BytesNeeded,ServicesReturned,ResumeHandle) then Exit; Thanks, Kevin

Thanks for getting back. Sorry, I read somewhere on the internet that it was a function (to limit the IDE instance to one). WRT the help file, nope, that's what was presented when I installed GExperts from your website. Kevin

Hi, I have spent several days fighting my way through an install of JCL/JVCL. I'm using 10.4.2 CE. I have variously installed/uninstalled from GITHUB and GETIT. I'm now where I was several days ago in that (and the only version I installed was Win32). Now the installation all looks good. Successful completion messages, and paths all set. BUT when I do a Build of the first project I get this message: 'Your Delphi/BCB version is not supported by this JVCL version!' YET if I look at the inc file (where this message was generated jvcl.inc), it clearly is: {-----------------------------------------------------------------------------} {$IFDEF BCB21} {$IFDEF CPUX86} {$I jvcld21win32.inc} // same include file for BDS based C++ {$ENDIF CPUX86} {$IFDEF CPUX64} {$I jvcld21_x64.inc} {$ENDIF CPUX64} {$DEFINE JVCL_CONFIGURED} {$ENDIF BCB21} .... .... {$IFNDEF JVCL_CONFIGURED} {$IFDEF SUPPORTS_COMPILETIME_MESSAGES} {$MESSAGE FATAL 'Your Delphi/BCB version is not supported by this JVCL version!'} {$ELSE} 'Your Delphi/BCB version is not supported by this JVCL version!' {$ENDIF SUPPORTS_COMPILETIME_MESSAGES} {$ENDIF !JVCL_CONFIGURED} I am at a complete loss. Of course I could simply hardcode $DEFINE JVCL_CONFIGURED, but that addresses the symptom not the problem. Does anyone have any idea of how I might fix this. A simple install has so far taken several days. Thanks, Kevin

Hi, First time here (just got the Google Groups and it has died). Look, this might be a simple issue and if it is I apologise, but it is driving me spare. Reading the literature I was under the impression you could build for OSX and use the debugger as you would in say a Win32 app,ication, ie. you would have breakpoints and could single step through the code if required. When I build for OSX I have never seen anything like this. The Event Log always says 'No Debug Info'. The best I have been able to do is to use log.d from FMX.Types to show log messages in the PAServer window. I really have tried searching everywhere and anywhere and cannot see anything that would enable what I would call 'normal' Delphi debugging. I think I have all of the necessary debug options set (the debugger certainly works as expected when I build the code for Win32/Win64). Specifically this was a working 32 bit application and DLL that I have converted to a macOS app and DYLIB. I can get the DYLIB to load and functions called if I have a simple test application as the host NOT the converted application. The reason it is now quite desperate is that I'm getting an AV and here's the scenario: Delphi 10.2.3 OSX 10.13.6 PAServer 19.0 Xcode 9.4.1 So my issue with code: Main Program and My Dylib Both call a common unit that generates log file (log4pascal as modified by me) At startup I get Log.d message that now in Initialize Block of log4pascal (it sets up logging for the DYLIB and main application) I then get a Log.d message code is in the Initialize Block of the DYLIB I then get a log.d message that code is leaving the Initialize Block of the DYLIB (all good so far) I SHOULD now get a log.D message that it is entering the Initialize Block of the Unit associated with the main application Instead I get an AV - see attached OSX AV And the PASERVER log shows the same - See log-lines below So the Initialize Block code for the main unit for the application itself is a Log.d line, it NEVER gets executed, ie. the AV occurs before it gets to Initialize? I am having significant difficulty tracking this error. So my initial problem is essentially ...how do i get the debugger to work when running an OSX application so that I can track down that AV (ie. with features like setting breakpoints and single stepping through the code??? Or do I have this all wrong, is there some other way I should be doing it (the Embarcadero documentation suggests I should be able to debug OSX in the same way as I debug Win32 apps). Again, if this is simple stuff I apologies, but it has me stuck.... Kevin

Hi Dave, That was one of the options. Basically the test calls two of the functions in the DYLIB. The 'actual' main app is far more complex and I use TMultiThread2 with callbacks etc etc. Works fine in the Windows world. I had initially started by commenting out great slabs of code and it did work with only the two functions called, but it's messy. What I don't get is why I get an AV on initial load - OSX loads the DYLIB first (successfully) then before it can get to the initialise block in the main app an AV occurs - I don't get what code could be generating this. But yes, cut code and see where it actually works.... Did you see my myriad of comments about a stack trace? I'm happy to send you the stack trace, but can you tell me how to actually get one?

And again, at the risk of too much info, I can and have used MadExcept successfully in the Windows environment. Here I force an AV and the error is logged, but NOTHING in the Delphi stack trace window (Line 325 is the function declaration, the actual error is at line 931 calling that non-existent DLL function). So, yes, MadExcept (and I'm sure the others) works fine, but they don't translate to the OSX world: program DropboxDLLTest; uses {$IFDEF MSWINDOWS} madExcept, madLinkDisAsm, madListHardware, madListProcesses, madListModules, {$ENDIF MSWINDOWS} FMX.Forms, EmpyreanMain in 'EmpyreanMain.pas' {frmEmpyreanMain};

And I might be getting confused because when I read the Embarcadero documentation (for Tokyo), it quite explicitly states that to get a stack trace you need to use one of the stack trace providers. All of the stack trace providers only works on Windows, I don't see any of them that actually work on OSX. Am I just reading this incorrectly?

Hi Dave, Thanks for the reply. As noted I don't seem to be getting ANY debug info other than what's logged by log.d calls in the PASever windows: I get this in the PAServer terminal (the unknown compressor happens whether it works or not): And when I run the application there is nothing in the Debug Stack Trace Window. That was part of my original question. I thought I have done everything to setup debugging on OSX, but I just don't get any debug information other than what I actually write through Log.d or show message? Is / are these some 'magic' settings that I need to turn on? I've been through the docs and I 'thought' I had done what was required (obviously not). This was the same when I had the FMXApplicationDelegate registration error reported via stack exchange, you asked for the callstack which I don't seem to be able to get? Any ideas hints how I might get the callstack, this seems key to solving most problems if you can identify where they occur? Win32 Oh, and as noted, same code works fine in win32, no sign of an AV, BUT I also get nothing in the stack trace windows. If I run the app Win 32 if I put in a breakpoint I can single step through the code and the CallStack for the current thread is visible, but still NOTHING in the stack trace Window. Thanks..... OSX BUILD WINDOW:

@Sherlock Thanks for taking the time to reply. The DYLIB is for use by others that have code in C++ and Swift, the good old Delphi way, simple as it would be, and I wish I could avoid doing the DYLIB thing because there is little information and almost no one knows how to build DYLIBs, just would not cut it. For example I contacted TMS about their FMX cloud pack and they said they had never even considered DYLIB testing and would not consider it, too much effort. So cross-platform is cross-platform with serious limitations. I’m actually evaluating whether Delphi is a viable tool for OSX, because it does not live up to the hype, that’s for sure. I have ave a Log.d statement in the last line of the DYLIB initialisation statement which gets executed first when the DYLIB is loaded and as the first line of the initialisation section of the main app unit. It never gets to the main app units initialisation section. Log.d in this case is pretty useless.