JonRobertson

Just my experience, I had major issues with IDE instability when I started using Delphi 11. I had a call with one of the product managers and showed the issues that I was having. His suggestion was to remove packages and add-ins to find the cause, which I had been too lazy to do at that point. Once I removed Navigator and Bookmarks, all of the IDE instability disappeared and I've rarely had an issue since.

Probably. Microsoft changes how they think the Windows UI should work on a regular basis.

This is a stretch, but you could extract the manifest from your bds.exe and verify that the manifest is not requiring elevation. The link has a sample command-line, which I just used on my bds.exe. If you have Visual Studio installed, mt.exe should already be on your machine. I don't know if there is a way to get it that is simpler than installing the Microsoft Windows SDK. I can't imagine this is the cause with a standard install. But there is something triggering the request. The manifest should contain this line: <requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>

You could try an alternative to Lajos' suggestion. Manually launch a second instance of Delphi, and then use Run->Attach to Process to attach to the first. You will want to check Task Manager before launching the second instance, to get the PID of the first. You will see both instances in the Attach to Process dialog.

Installing the package will require Delphi to call Register. I doubt that Delphi calls Register every time it loads a package. @Dave Craggs Since you are building, do you have source for all of the components in the package? You could add OutputDebugString logging to the Register procedure as a start, to narrow down the component causing the AV.

Have you tried launching BDS with a different registry key? This would not load components installed after the IDE was installed. In my tests, experts and add-ins are still loaded. For example: bds -r"clean" I wonder if there is something else (such as a DLL) being loaded by the IDE that is triggering the elevation requirement. Using Process Monitor could be helpful to track what BDS is doing before the elevation dialog appears.

Either the error you posted is not a true copy of the error message or something is wrong in your DPROJ. There are no "vcl.dcp.vcl.*" files in the Releases folder or any other folder under Embarcadero\Studio\... My suspicion is that you are building a project for 64-bit and the compiler is finding a DCU previously built for 32-bit. If the unit's source has not changed, the compiler will not rebuild the DCU even though the DCU was built for a different platform. I wish the compiler dealt with this better. The first thing to try is Project->Build (Alt-P then B, or Shift-F9 should also work). If you still get a similar error, post the error message again and your DPROJ file, if possible.

That would work for a DLL that contains native code and uses ANSI char based null-terminated strings. The code posted is C# code, using a .NET System.String class "Representing text as a sequence of UTF-16 code units" The DLL generated will be a .NET assembly containing managed code, not native code. As Peter mentioned earlier, either the DLL has to be written & compiled to support COM interop https://blogs.embarcadero.com/using-a-net-assembly-via-com-in-delphi/ https://www.blong.com/Conferences/BorCon2004/Interop2/COMNetInterop.htm#CCW or the Delphi application that loads the DLL has to host the CLR before the DLL is loaded. https://stackoverflow.com/questions/2048540/hosting-clr-in-delphi-with-without-jcl-example https://stackoverflow.com/questions/258875/hosting-the-net-runtime-in-a-delphi-program https://en.delphipraxis.net/topic/1744-net-runtime-library-for-delphi/ https://adamjohnston.me/delphi-dotnet-interop-with-jvcl/ "Explain step by step" isn't possible, as there are a lot of factors to consider. I suspect this is why there are commercial libraries that do this. https://www.remobjects.com/hydra/ https://www.crystalnet-tech.com/ https://www.atozed.com/crosstalk/ There was a library called Managed-VCL, which can be found online. But the website vanished a while back.

You have a couple of "bundles". Do you mean the three library bundle? I'm curious as a potential customer.

Different languages have different rules and syntax. Is that really an issue? I see the "issue" as developers using the incorrect syntax for the language they are currently using. If I toured Italy, I imagine my trip would be more enjoyable if I spoke Italian. Which I don't.

Should that matter? I started learning Pascal 35 years ago and C the following year. Not once have I written c := (a < b) ? a : b; or if (a == b) { doSomething(); } while writing Pascal code.

Works for me as well in 11.3.

What do you get when you try const sig1: FileSig = (Offset: 10; arrSig: [$00,$01,$02]; ) in D2007?

Unfortunately, many are still just that.

I have a lot of respect for your knowledge and experience, seeing some of the work you have done. However, I think that is a fairly bold assumption. Since 1996, I have preferred Delphi over other development tools/languages/frameworks. I do not enjoy doing GUI work. But I believe a lot of what "operates the world" is line of business apps, whether they be for commerce, government, health care, or hundreds of other industries. Computers can't read our minds (thankfully). And voice recognition is not that reliable. I see proof of that every time my mother-in-law sends a text.

TIniFile will work on any file that conforms to the INI file format, and it seems the RemoteHost.cfg that you have uses the INI file format. But many, if not most, .cfg files will use a different format that isn't compatible with TIniFile.

Always pay attention to compiler warnings and hints. Most of the time, the compiler is being helpful. Had you resolved the compiler warning, you would have solved the issue without needing assistance. Asking for assistance isn't a bad thing, that's the beauty of forums like these. But solving issues without assistance is even better, for me anyway. My opinion is that I am not "finished" with code unless it compiles with zero compiler warnings and hints. Sometimes I even add a statement just so the compiler will be "happy". I believe that W1036 should be an error rather than a warning, as using an uninitialized variable is almost always a bug in the code. I only say almost because I've learned there are exceptions to every rule. Warnings can be changed to errors at the project level. I have W1036 set to an error in my projects. This is done in project options. See this post if needed: state of an uninitialized variable try/finally should be a habit when any resource is created or allocated, or a state that should be undone, such as setting Screen.Cursor or calling methods such as DisableControls/EnableControls and BeginUpdate/EndUpdate. Once you've developed the habit, you won't even think about doing it. It'll just be natural. And it'll avoid a lot of potential headache. I neglected to mention it earlier because it was end of day on a Friday and I was ready to leave the office. Oops!

You are likely getting an AV because RHini is not initialized to nil. As a local variable, it has a random value until initialized. You should have a compiler warning: [dcc32 Warning] W1036 Variable 'RHini' might not have been initialized Change your top line to: var RHini: TIniFile := nil; or perhaps var RHini: TIniFile := TIniFile.Create(AppDir +'\RemoteHost.cfg');

Have you tried using TIniFile and the various Write* methods to write the needed values to the .cfg file? If there are numerous writes, you could use TMemIniFile. System.IniFiles.TIniFile

I completely agree. Unfortunately, people who write the "corporate check" don't always agree.

Not at all. I'm sharing what seems to be an opposing opinion. I suppose to clarify any miscommunication, since your ideals about what "I prefer" were opposite of what I actually prefer.

Yes, although more of a helper. Removes the with identifier do [and begin/end statements if present] and copies "identifier." to the clipboard so you can easily paste it where needed. It does not automatically determine which fields need the "identifier." added. Very simple example: Before: with Form1 do begin Left := 200; Top := 100; end; Invoke MMX Convert with: After: Left := 200; Top := 100; And "Form1." is in the clipboard to be manually pasted where needed.

Hopefully not with Shift-Alt-W (MMX Convert with statement) is a good friend of mine when "migrating" legacy Delphi code.

If you are familiar with other programming languages, I ran across a Cross Reference site that could be useful. It currently cross references 14 languages. Cross Reference Coding

That is just nonsense in my opinion. Of course the details of a trial are relevant to the trial. Saying otherwise is almost as inconceivable as saying the details of the license agreement are irrelevant to my use of a software product or developer tool. What about the page that quite clearly says at the top Download AppGini Free Trial Or perhaps on the Frequently Asked Questions page, for someone like me that would want to know.