ByteJuggler

Please always post the actual error message you're getting. Has there been compiler upgrades? When did this stop working? Does this happen in an older version of Delphi? Any other changes? (SQL Server driver changes?) If this is Delphi version related then it smells like some kind of datatype mapping change/issue in Datasnap. You might try constructing the CDSSv first by hand, to control the datatypes explicitly, rather than relying on the provider machinery + query to essentially create it for you. You might also experiment with different versions of midas.dll (or whatever it's called nowadays, assuming it still exists. -- Not currently using Delph and/or familiar with Delphi 11 changes.)

Hmmm. Kind of hard to guess without more information. But, try trapping/putting breakpoints in all relevant/related object destructors and explicitly nil every object reference where possible straight after to make nil pointer derefences very obvious. I'm inclined to think something is being freed and subsequently used without you realising and then you're tripping on an invalid reference. The traps and setting to nil I suggest is intended to help catch where. (That unguarded/unchecked FfrmMain reference in StatusOut() seems a bit suspicious in particular. Ensure FfrmMain gets set to nil when the object it points to is destroyed, e.g. in the form class destructor [of course, only if self = FfrmMain!]) and then also only access memStatus in StatusOut if FfrmMain is [still] Assigned.) Of course I could be barking up entirely the wrong tree. (I'd add, I worked on a codebase with somewhat similar goings on at a point, which worked fine, though it was the case that you could easily be hoisted by your own petard if you're not very careful, as seems to be the case here also -- there was some similar issues at one point due to message arriving in the message queue after the Release message and then code like above assumed objects were still there that actually weren't etc., or something of the sort as I recall, so I'm wondering whether something similar is going on.) Also, the Application.ProcessMessages is also a bit suspicious and smelly, although it's might not be a problem per se here. (It's unclear offhand to me why exactly that's there, I'd be inclined to remove it to eliminate it as a cause of trouble unless you absolutely know that it is required to avoid some other behaviour.) Do you use something like MadExcept or Eurekalog? (Have you got more context about what's actually happening?) I might perhaps be open to a quick realtime screenshare look in person if you're open to this? (Discord, Zoom, Skype) Maybe another pair of eyes can help.

Yes... See if you spot what files, keys, or otherwise handles are being accessed/read/written and whether some stand out as being sluggish, and/or whether some of those events are excessive or slower than normal. Your problem may be inherent to the compiler linking phase and so maybe somewhat unavoidable, but this hypothesis seems dubious since you state that this has begun to be slow and so was previously quick. And generally Delphi really doesn't take long to link. So, something must've therefore changed to cause this one would think. (Random thought: I suppose it's worth checking the underlying disk/filesystem that the VM's virtual disk is on for problems, though I imagine this is fairly obvious and you may well have done this already. Another question, is this in the IDE or via command line compiler? If the former, have you tried the latter? Either direct or via MSBuild which is a easy way to compile a project without having to think about the command line compiler switches?)

Orthogonally to the suggestions from Pawel, I'd suggest also trying to analyse what the step is actually doing while it's "being slow", with ProcessMonitor. Even the built in Windows 10 Resource Monitor, which you can get to from the Task Manager in Windows, can be fairly useful as it allows you to isolate and drill into individual processes to monitor their behaviour as well, including handles/files opened/loaded etc etc. Understanding what it's actually doing and working out why this step is being slow might give you ideas on how to avoid it.

<humour ascerbic="true">This is due to the relationship between "theory" and "practice". In theory there's no difference between theory and practice. In practice, there is. </humour>

Long time ago yes. But it's quite possible and fairly easy to do mostly what it does (in respect of having a single app that can have GUI or run as service) with just a bit of code rearrangement needed, kind of similar to what aehimself has done. (One service here compiles as APPTYPE CONSOLE/will run as service by default, however it can "convert" itself on startup into a GUI app (which it does by calling FreeConsole() and then creating a main form in the normal way) if it finds a command line switch telling it to do so (e.g. -ui). Otherwise it will start in the normal way as a service app by setting and calling the usual stuff that's called for a service app (e.g. CoInitFlags, SvcMgr.Application.Initialize(), SvcMgr.Application.CreateForm() and finally SvcMgr.Application.Run(). etc)

Hi, Has anyone recently used the ObjectToJSON function from SynCommons.pas from Synopse's mORMot framework? If so can you have a look at the following post: https://synopse.info/forum/viewtopic.php?pid=30271#p30271 It must be me missing something obvious, but it seems slightly broken to me. 🙂 Edit: Never mind! I worked out what I'm missing. You basically have to also add the mORMot unit to your uses clause, to ensure that TJSONSerializer is set as the default writer instead of TTextWriter.

In case anyone else runs across this thread in the future and are stuck trying to import the type library for MS Word (WinWord.exe), note that unlike with Excel where the type library can be imported from the .EXE file, with WinWord the Type Library is not embedded (it seems) in the .EXE file, so you run into an error if you try the same approach as above. It turns out that for many Office applications the type library information is stored in .OLB files. For more on this see: https://docs.microsoft.com/en-us/office/troubleshoot/office-developer/use-type-library-for-office-from-visual-c-net The full command i used to import the type libraries related to MS Word (WinWord) was: "C:\Program Files (x86)\Embarcadero\Studio\18.0\bin64\tlibimp.exe" -P "C:\Program Files\Microsoft Office\root\Office16\MSWORD.OLB" Adjust as required for the version of Delphi and/or Office you're using. The files will be created in the current folder, so be sure to be in the target folder before you run the command. The output is something like this: C:\temp\import>"C:\Program Files (x86)\Embarcadero\Studio\18.0\bin64\tlibimp.exe" -P "C:\Program Files\Microsoft Office\root\Office16\MSWORD.OLB" Embarcadero TLIBIMP Version 12.16581 [x64] Copyright(c) 1995-2010 Embarcadero Technologies, Inc. Opening C:\Program Files\Microsoft Office\root\Office16\MSWORD.OLB Type library loaded .... Created C:\temp\import\Office_TLB.dcr Created C:\temp\import\Office_TLB.pas Created C:\temp\import\VBIDE_TLB.dcr Created C:\temp\import\VBIDE_TLB.pas Created C:\temp\import\Word_TLB.dcr Created C:\temp\import\Word_TLB.pas C:\temp\import> Hope that helps future me or some other soul... 🙂

Yes, IIRC you're correct. We had to (IIRC) use the .dproj file switch because for whatever reason (bug?) the compiler ignores the compiler directive but does respect the .dproj flag. (To add, in our case the "C++ output file generation" was also already off, however the compiler still emits/emitted this warning from one of the Synopse modules e.g. SynCommons.pas: "'ESynException.CreateLastOSError' with identical parameters will be inaccessible from C++" (and checking the module was being recompiled from scratch.) The only way that worked was the .dproj flag.

You are of course correct. Thanks. I should've looked and thought harder before posting.

I haven't, thanks. I'll try it Monday. (Seems a facepalm is incoming.) Thanks again. 🙂

I have an irritating hint that I'm trying to get rid of ("warning W1036: Variable 'xxx' might not have been initialised" or with initialisation supplied and with project options disabling Assertions the same block of code emits "Value assigned to 'xxx' never used".) The root of the problem is that there's an initializing assignment which sets a variable to zero, followed by some logic, followed by an Assert that checks against the variable. The trouble happens because of the different "Assert" compiler option in force between RELEASE and DEBUG. Under DEBUG mode (for this particular project) "Assertions" are set to True, which means during compilation the Assert() line is not elided (removed), and the compiler therefore (correctly) demands (hints) that the variable being asserted against should be initialised with the first message if not done. Obviously adding an initialising line fixes the hint for DEBUG mode. However, if you then compile the same code in RELEASE mode (for which "Assertions" are set to False), then the Assert() line is elided during compilation. This means the variable initialization is now redundant and then the result is the compiler hint "Value assigned to 'xxx' never used", which (correctly) demands that the initialisation line should be removed. The question is essentially how to fix this so the code can compile successfully without hints both with DEBUG and with RELEASE settings, e.g. both with Assertions enabled and disabled. More concretely, the implication of the above is that to fix this, the initialization code must be conditional and somehow only be included only when assertions are enabled and omitted/removed otherwise, since the initialization is required only if the Assert() check is going to be done. Hence the title of this post and my question: Does anyone know of a compiler directive or something to detect whether assertions are active that will allow me to correctly condition the inclusion of the initialisation assignment so as to eliminate this hint both when Assertions are enabled and disabled?

Correct.

No it doesn't appear in that list. And I've by now managed to solve the whole problem, thanks! 🙂 (As far as I can tell 🙂 Oh, and sans designtime component icons but that's hardly important.) I (vaguely) remembered that the Delphi IDE only lists the servers/type libraries/components listed in the 32bit registry, and then managed to (re)locate this page, which states this and mentions that despite the IDE choking on 64-bit imports (as I've found), the TLIBIMP.EXE command line tool works fine. I hence successfully used it to import the Excel 2016 library and built and installed them into the IDE. For reference the command used to import the type library was: "C:\Program Files (x86)\Embarcadero\Studio\18.0\bin64\tlibimp.exe" -P "C:\Program Files\Microsoft Office\root\Office16\EXCEL.EXE" There's some fiddling required with the output files to make them match Embarcadero's conventions on their own imports (e.g. change from *_TLB.pas to *2016.pas in this instance). You also obviously need to create a Delphi component project to contain the wrapper components, which should be named dclOffice2016.dproj assuming you want to again match Emba's conventions. Inside the project options you should then also set the library suffix to match the product version that you're using and probably set a suitable description. (In my case Delphi Berlin which is product version 24 and suffix 240 as shown here.)

Hi all, I'm trying to import the Excel 2016 type library into Delphi in the normal way via "Component"->"Import Component"->"Import ActiveX Control", click "Add", browse to "C:\Program Files\Microsoft Office\root\Office16\EXCEL.EXE" (list changes and has only the selected type lib loaded), "Next>>", filling in the fields as desired, and then clicking "Next >>", Selecting "Create Unit" and clicking "Finish" which then generates the below error ("Error loading type library Excel (Version 1.9).") https://i.vgy.me/DvFI6h.png I've also gone to the trouble of extracting the actual Type Library resource from Excel.exe using Visual Studio and importing that directly instead. (In the above process you select "Import a type library" instead of "Import ActiveX Control".) The result is essentially the same, e.g. the same error is generated. I should note that this is the 64-bit version of Office that is installed, and I'm aware that I've tried to directly import the server/tlb interfaces directly from the 64-bit Excel executable and that this might be part of the problem. I'm unsure whether this is legitimate or whether that's part of the problem, but if this is a problem I'm not sure what I should be importing instead? (Is there some kind of 32-bit wrapper library that I should be importing instead? If so what?) Thanks!