Brian Evans

It uses Ruby Rack which is: Rack provides a minimal interface between webservers that support Ruby and Ruby frameworks. Rack is a layer between the framework & the application server — RubyRack The needed config file is in the root directory (config.ru).

CodeSite is an optional logging library. Delphi includes a limited version called CodeSite Express available through GetIt. Conflicting information if it is available with Delphi CE.

I agree it is bad move to create the problem - limited activations with no way to de-activate - then require a support contract to 'fix' it with a bump to the number allowed. As others have mentioned it seems more like a car salesman's slimeball tactic to increase 'sales interactions' than provide any benefit to customers. The policy basically says to active developers trying to reinstall: Give me money or you can go f*** yourself. That is not how you build a developer community. It is likely driving away a good number of developers and killing sales in the long term for a few renewals in the short term. In my estimation they should just allow three and decay them one per year. More than that by request with justification. Or just bring back a way to do it self-serve style like it was before with some upper limit based on time.

You can put the BPLs in the same directory as the EXE and always deploy both. You lose some of the sharing between unrelated executables but avoid extra testing and issues like this when there is a new release of Delphi or some third party library. The incompatibilities are usually fixed given some time but having to wait on them can cause it's own issues like delaying your own testing and/or deployment. I rarely use runtime packages but when I do they are only shared between executables built and deployed at the same time. For applications with long lives it keeps them from breaking when other installers change common files or even delete them on uninstall.

No error seen here dropping a TrzCheckList on a form in a new project.

How to open more edit windows in case it is hard to find. It is kind of workable but does have some quirks - often get a blank area with a Move Designer button when switching around a lot and select the same thing in more then one place.

Had similar errors for FMXLinux packages when I did the 11.2 install. I just clicked OK and continued on and made sure to install FMX Linux in GetIt before doing work in the IDE. Enough was installed that I could do the rest by launching Delphi and using the Platform Manager and GetIt there.

FMX does not have a Data Controls palette - it uses regular edits plus live bindings. View the source code of a form and check the uses clause. If it contains items like FMX.Types, FMX.Controls, FMX.Forms, FMX.Graphics, FMX.Dialogs then this likely a FMX project and not VCL. If it is not an FMX project try: Make sure you are in Design mode and not Code mode (tabs along bottom of editor) then right click in the Palette area and select "Reset Palette".

One option would be to use the (Windows Filtering Platform - Win32 apps | Microsoft Docs). This is the same set of APIs that the Windows firewall uses to interact with the Windows network stack to control traffic.

If that is hooked up to the edit in question. I have doubts since DBEditPMSExit wouldn't be the default event name for a control called DBEdit23.

Exit is not triggered for a control when the application is closed as focus never moves off it. You could move focus somewhere in the form's OnClose to trigger it. procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction); begin Form1.SetFocusedControl(Form1.Button1); end;

Would suggest using the Microsoft OLE DB Driver for SQL Server - OLE DB Driver for SQL Server | Microsoft Docs instead of ODBC. Without seeing your code it is just guessing why it is slow. Certainly a large difference between local and over the network suggests your code isn't using ArrayDML with a large enough batch size or any batch size at all.

No problems encountered here. Expand the tree nodes and see more details on what is going wrong. Can also take a look in C:\Users\Public\Documents\Embarcadero\Studio\22.0 for GetItInstall.log which should also have the information on what happened.

As with any software without a reliable method to reproduce a bug it can be very hard to fix it. Some organizations severely limit how much effort can be put into non-reproducible bugs as they can consume large amounts of time and effort for little to no gain. It is frustrating for both users and developers but acting out on that frustration doesn't really help any. For F2084 Internal Error errors which are often due to the compiler having problems with some source code it is very hard to find the bug and create a way to reproduce it without access to some source that triggers it. Again frustrating for both - it is hard for developers to do much with "compiler chokes on my source" when they can't take a look at the source - but also for the user who has work interrupted when the hit the bug. At least when there is a way to reproduce a problem Embarcadero does work on fixing them. An example was for years I occasionally got a dangling scrollbar in the IDE but never reported it since I was not able to find a reliable way to reproduce it. A while back somebody did report it and after reading some comments others made I finally managed to reliably reproduce the issue and put it in a comment on the bug report. It was fixed in the next release. ([RSP-34111] Editor leaves dangling vertical scrollbar behind - Embarcadero Technologies).

One place they are used in OAuth 2.0 is when exchanging a refresh token for a new access token. How long refresh tokens and access tokens last depend on the web service being accessed. One example would be : Refresh Tokens with OAuth 2.0 - LinkedIn | Microsoft Docs