Remy Lebeau

It is "up", but it is not entirely stable. I was just using it a few minutes ago and still got a few errors on it. But yes, I could access pages.

The parent list (https://stats.uptimerobot.com/3yP3quwNW) doesn't appear to include any GetIt servers for monitoring. Unless maybe they are listed under a different name (Downloads, perhaps?)

In the short term, yes. But on the other hand, external links tend to break over time, which makes discussions harder to follow for future readers who may be looking for solutions to similar problems, if they can't see the code that is being discussed.

Did you read the discussion I linked to earlier? You would have to modify the Registry directly. However... At the moment, not the online version, no. Several key systems, including GetIt, are completely down (and have been for over a week now!) due to a hardware outage: https://blogs.embarcadero.com/we-are-experiencing-a-hardware-outage/ If you really need access to GetIt right now, the best you could do is put GetIt into offline mode and let it work with its local cache/ISO, including any local packages you install into it manually.

You appear to be using TIdHTTPServer, so why are you using IOHandler.Write() directly at all? You should be using ResponseInfo.ContentText or ResponseInfo.ContentStream instead. Unless you are streaming data that is dynamically generated in chunks while the response is still being written to the client? That is not a common thing to do for HTML. Can you please show a more complete example of how exactly this AddStr() method is being used in relation to your server? How are you configuring the ResponseInfo before calling AddStr() the 1st time? Without more info, my guess is that you are probably violating the HTTP protocol in some way and the error is just a side effect. The error simply means the connection has been dropped on the server side, but that could happen for any number of reasons not directly related to your code.

That sounds more like a server-side issue, if it affects both components. Did you check if the requests are different in any way between Delphi 11 vs 12?

If you were using Indy's TIdHTTP, then it would automatically use IPv4 unless the requested URL is bracketed, eg: "http://[HostOrIPv6Address]/", which would force IPv6. For the RTL's THTTPClient, I have no idea how it behaves in regards to IPv4/IPv6.

It will be a full week tomorrow.

If you can ensure the submitted data is absolutely identical in both browser and Indy, then the only thing I can think of is if the server is sensitive to the User-Agent that is making the request. Some webservers change their behavior depending on which browser is asking, and it is not uncommon for webservers to behave weird/incorrect when encountering Indy's default User-Agent. Try setting the TIdHTTP.Request.UserAgent property to mimic Chrome, see if that makes any difference.

Did you make any changes to your setup recently? A search online suggests that Runtime Error 236 might be related to a mismatch between dependent package binaries. A search though the RTL source code suggests that Runtime Error 236 means the System.TMonitor class is crashing because its underlying support system is not initialized.

Depending on the length of the data, and just how many points are being sent, I probably would not have used the URL for that. WebServers tend to limit how much data can be sent in a URL query string. A POST body might have made more sense. Did you try comparing Chrome's raw HTTP request/response data to TIdHTTP's raw HTTP request/response data for differences? You can use Chrome's built-in debugger to get the HTTP data it exchanges over the wire, and you can attach a TIdLog... component to the TIdHTTP.Intercept property to get the HTTP data it exchanges over the wire. There were a handful of checkins for TIdHTTP between those 2 versions, but offhand I don't see anything that would affect what you describe. Offhand, the first thing that comes to mind is the formatting of {COORD1}, {COORD2}, etc. What does that actually look like? (without revealing real numbers. Can you use fake numbers?) The error message says to check the separators, do the coordinates have their own separators in them? If so, are you perhaps using locale-based separators in the formatting?

Indy is not in GetIt. It is preinstalled with Delphi itself. That is not the correct approach to take. If you need to control where the DLLs are loaded from at runtime, you should be using the Win32 SetDllDirectory() or AddDllDirectory() function instead. Or, you can also use Indy's IdOpenSSLSetLibPath() function. In any case, whether you use SetEnvironmentVariable() or (Set|Add)DllDirectory(), this API-based path update only affects the calling process, not the user/system as a whole. So, any app not running in your folder will need to do the same API update for itself to look for the DLLs in your folder. Unless you manually update the user/system config directly. That's exactly how they are intended to be used, and should be used. Unless you have a group of related apps that need to use the same version of the DLLs, then they can be shared in a folder that all of the apps agree on. My guess is either: - there is another version of the DLLs present on the system, which is not compatible with the server in question, and the failing app is finding those DLLs instead of the ones you want. You should have the app log out the full paths of the DLLs it actually loaded into memory (not the paths it thinks it loaded). - the failing app is not configuring the DLLs properly to work with the server in question. There is not enough information provided to diagnose your problem one way or another. We need to see your ACTUAL setup, and your ACTUAL code.

The event is signaled when TerminatedSet() is called. TerminatedSet() is called by the Terminated property setter. If the thread is still running when the TThread object is being destroyed, the inherited destructor will set the Terminated property and wait for the thread to finish running.

Several of Embarcadero's systems have been down since Friday night, including QualityPortal, DocWiki, GetIt, Blogs, etc.

That means you are creating the TTimer in the main thread to begin with, not in the background thread. That's exactly how TTimer already works. Its constructor creates a hidden window in the calling thread, which when activated will then receive timer messages from that same thread. So the thread that creates the TTimer must have a message loop to receive and dispatch those timer messages. So, you might think about moving the creation of the TTimer into the background thread's Execute() method, and that may work 99% of the time, but know that the creation of that hidden window is not done in a thread-safe manner, so you really should not be using TTimer in a background thread at all. If you really need a thread-based timer, you could just use the Win32 timeSetEvent() function, which is a multimedia timer that runs its callback in a background thread that the OS manages, If you really want to use a custom TThread class, then using TEvent is the simplest option that allows you to terminate the thread on demand, eg: uses ..., Classes, SyncObjs; type TTimerThread = class (TThread) private fEvent: TEvent; fInterval: LongWord; fOnElapsed: TNotifyEvent; protected procedure Execute; override; procedure TerminatedSet; override; public constructor Create(AInterval: LongWord; AOnElapsed: TNotifyEvent); reintroduce; destructor Destroy; end; constructor TTimerThread.Create(AInterval: LongWord; AOnTimer: TNotifyEvent); begin inherited Create(False); fInterval := AInterval; fOnElapsed := AOnElapsed; fEvent := TEvent.Create; end; destructor TTimerThread.Destroy; begin fEvent.Free; inherited Destroy; end; procedure TTimerThread.TerminatedSet; begin fEvent.SetEvent; end; procedure TTimerThread.Execute; begin while fEvent.WaitFor(fInterval) = wrTimeout do fOnElapsed(Self); end;

Why is the code creating the TStringStream object in the constructor and destroying it in the destructor, instead of just using it locally inside of Execute()? Do other threads need access to the TStringStream? If not, then it doesn't need to be a class member.

Their system went down late Friday night, multiple servers were affected, including DocWiki, Blogs, QualityPortal, etc. Last I heard, they are still working on resolving the problem.

How exactly are you attempting to open the file? Are you getting an error? If so, what is it? I'm no Android expert, but outside of a public folder, I think Android does not allow two apps to share files with each other unless both apps cooperate with each other, ie the providing app has to grant access to the receiving app. And since the providing app in this case is no longer available, you might be SOL. 🤷

Why? What are you planning on doing with otares files if you could get them generated? Delphi doesn't use otares files anymore, it's a legacy thing only.

No. I just knew the feature supposedly exists. Ouch! And not even opened for review yet....

Nope. Eof simply evaluates the current record, it does not move to another record. Hence the need to call Next() explicitly. Yes.

In a word, no. However, if you intend to use the extended component in just one form/project, and don't mind setting the new properties in code at runtime rather than with the Object Inspector at design-time, then you could use an interposer class to add the properties, and that way you don't have to make the extra effort of putting the new component in a new package and installing it into the IDE. For example: unit MyUnit; interface uses ..., Vcl.Forms, Vcl.StdCtrls, System.IniFiles, ...; type TCheckBox = class(Vcl.StdCtrls.TCheckBox) public IniSection: string; IniProperty: string; procedure LoadFromIni(Ini: TCustomIniFile); procedure SaveToIni(Ini: TCustomIniFile); end; TMyForm = class(TForm) SomeCheckBox: TCheckBox; procedure FormCreate(Sender: TObject); ... private procedure LoadConfig; procedure SaveConfig; end; ... implementation ... procedure TCheckBox.LoadFromIni(Ini: TCustomIniFile); begin Checked := Ini.ReadBool(IniSection, IniProperty, False); end; procedure TCheckBox.SaveToIni(Ini: TCustomIniFile); begin Ini.WriteBool(IniSection, IniProperty, Checked); end; procedure TMyForm.FormCreate(Sender: TObject); begin SomeCheckBox.IniSection := ...; SomeCheckBox.IniProperty := ...; end; procedure TMyForm.LoadConfig; var Ini: TIniFile; begin ... SomeCheckBox.LoadFromIni(Ini); ... end; procedure TMyForm.SaveConfig; var Ini: TIniFile; begin ... SomeCheckBox.SaveToIni(Ini); ... end;

I updated my earlier example. Make sure CmdLine is not pointing at a string literal when passing it to CreateProcess(), as the 2nd parameter of the Unicode version of CreateProcess() (CreateProcessW) is not allowed to point at read-only memory.

Use the Win32 CreateProcess() function. Of course, a better option might be to NOT shell out to openssl.exe at all, but to use the OpenSSL API directly in your own code instead. It really depends on what you are trying to accomplish exactly. Only if you execute them as parameters to cmd.exe. Then you are doing something wrong, but we can't see what you are actually doing. Please show your actual code you are having trouble with. For example: uses ..., Windows; procedure RunCommandLine(CmdLine: String); var si: TStartupInfo; pi: TProcessInformation; begin {$IFDEF UNICODE}UniqueString(CmdLine);{$ENDIF} ZeroMemory(@si, SizeOf(si)); si.cb := SizeOf(si); if not CreateProcess(nil, PChar(CmdLine), nil, nil, False, 0, nil, nil, si, pi) then RaiseLastOSError; ... CloseHandle(pi.hThread); CloseHandle(pi.hProcess); end; ... RunCommandLine('C:\path\openssl.exe version'); Just note that openssl.exe is a console app, so if you run this code in a non-console program, it will create a new console that will close when openssl.exe exits. If you actually want to see the console window to read the output, or even to capture the output into your own code, requires more work than this code shows.

Feel free to file a feature request with Embarcadero