Remy Lebeau

You mean WM_COPYDATA, not WM_COPY.

I would rewrite that to something more like this instead. Don't duplicate code that doesn't need to be duplicated: var LCount: Integer; LCount := o.{$IFDEF JSONOBJ_HAS_COUNT}Count{$ELSE}Size{$ENDIF}; if LCount <> 3 then raise Exception.CreateFmt(_('Parsing error on JSON answer: Root object size is %d not 3.'), [LCount]); I would just write a class helper or separate function, and IFDEF the code inside of it. Class helpers were first introduced in Delphi 2005, but were buggy and not officially supported until Delphi 2006. JSON was first introduced in Delphi 2010.

SuperObject is open-source. Just diff the two versions to see what is different between them. Or, just update the D2007 code to use the same version that the XE7 code is using. Or update both codes to the latest version. So pick ONE and stick with it for both codes. I don't do JSON processing in my code.

Agreed. If IsSuspended were a manual-reset Event or ConditionalVariable, the main thread could sleep on it more efficiently. Or, on Windows 8+, you can use WaitOnAddress() to make the main thread sleep while it waits for the boolean to change value.

Rather than polling, you might consider letting the OS notify you when the file is being used. There is no guarantee that other apps will actually keep the file open while they are working on the data. In fact, it is not unusual for an app to open a file, load the data, and then close the file, and then reopen the file later only if new data is being saved.

To use a TFileStream just to check if the file is in use, you need to use fmOpenRead instead of fmCreate, and you definitely need to use fmShareExclusive instead of fmShareDenyNone, and note that the file could fail to open for any number of reasons, not all of which are related to the file being in use, so you have to check for that, eg: function FileReallyIsInUse(fName: string): boolean; begin Result := False; try TFileStream.Create(fName, fmOpenRead or fmShareExclusive).Free; except on E: EFOpenError do Result := GetLastError() in [ERROR_SHARING_VIOLATION, ERROR_LOCK_VIOLATION]; end; end; However, the exception doesn't carry the error code, and using GetLastError() after the exception is raised does not guarantee the original error code is preserved. You are better off simply calling the Win32 CreateFile() function directly instead (which avoids the need to allocate an object in memory, or invoke the overhead of exception handling): function FileReallyIsInUse(fName: string): boolean; var hFile: THandle; begin hFile := CreateFile(PChar(fName), GENERIC_READ, 0, nil, OPEN_EXISTING, 0, 0); if hFile <> INVALID_HANDLE_VALUE then begin CloseHandle(hFile); Result := False; end else Result := GetLastError() in [ERROR_SHARING_VIOLATION, ERROR_LOCK_VIOLATION]; end; Or, the RTL's FileOpen() function: function FileReallyIsInUse(fName: string): boolean; var hFile: THandle; begin hFile := FileOpen(fName, fmOpenRead or fmShareExclusive); if hFile <> INVALID_HANDLE_VALUE then begin FileClose(hFile); Result := False; end else Result := GetLastError() in [ERROR_SHARING_VIOLATION, ERROR_LOCK_VIOLATION]; end;

That is exactly what a TForm's PopupParent property is meant for. A TForm stays on top of its PopupParent Form, it can never go behind the PopupParent. Like I described earlier in this same discussion. Otherwise, just use a TFrame instead. Put it on top of the TForm that needs to be "blocked", and disable access to the TForm's controls until the TFrame is dismissed.

Only windowed controls (TWinControl descendants) can receive input focus, and thus be assigned as an ActiveControl. TLabel is a graphical control (TGraphicControl descendant), not a windowed control. If you need a windowed text label, use TStaticText instead of TLabel. TBitBtn is a windowed control. All windowed controls support that. All components, visual and non-visual, support that. The reason that doesn't work for you is most likely due to OS theming. So turn off theming on the button. Or, use a 3rd party button that allowed custom coloring. Or, just owner-draw the button yourself manually. I don't think any standard controls support vertical alignment, only custom-drawn controls can do that. All controls support that. For controls that are just wrappers for standard OS controls (like TButton), that behavior is controlled by the user's system settings, not by the framework. Most controls support that. Even if the event is not exposes, it still exists in all controls. Why are you posting this in a Delphi forum and not in the Lazarus forums? https://forum.lazarus.freepascal.org

Then why is this being posted in a Delphi forum and not in the Lazarus forums? https://forum.lazarus.freepascal.org

RFC 3659 Well, not just undocumented, but implementation-defined. Servers can (and do) use whatever format they want for LIST.

Is your component visual (derived from TControl)? Or is it non-visual (derived from TComponent)? Non-visual components can be used in both VCL and FMX without splitting up the implementation (just IFDEF the pieces you need). But visual controls take more work to design for separate frameworks. Then those lines should be in separate units. The rest of your code should be in a common unit(s) that the framework-specific units can then use. This is where Unit Scope Names come into play. Create separate VCL-specific and FMX-specific projects with appropriate Unit Scope Names specified in the Project Options, and then don't use any Unit Scope names in your code. That way, you have less IFDEF'ing to do. Your common gtDocumentPrinter code should be in its own separate unit, not in an include file. All the more reason not to use an include file.

Probably because the IDE is not HighDPI-aware, so it gets stretched by the OS. It wasn't necessary to show EVERYTHING, most of that code is not related to painting.

You are going to have to show your actual painting code. The fundamentals of painting controls haven't changed over the years (certainly newer APIs - ie theming - have been added, but that is secondary). Your old painting code should still be functioning the same way it always did.

Setting the Text property replaces the ENTIRE contents of the Memo. If you want to APPEND a line to the EXISTING text, use the Lines.Add() method instead, eg: Memo1.Lines.Add(lineoftext); In which case, your entire loop can be replaced with a single LoadFromFile() instruction, eg: procedure TForm1.Button4Click(Sender: TObject); begin Memo1.Lines.LoadFromFile('Test.txt'); end; Or, if you want to append the entire file to the end of the EXISTING text, do what Lars Fosdal showed you - load the file into a TStringList first, then you can AddStrings() that into the TMemo. If you really want to manually loop through a text file line-by-line, consider using the TStreamReader class instead of old-style Pascal file I/O. TStreamReader has a ReadLine() method (and in Delphi, it supports Unicode text encodings), eg: procedure TForm1.Button4Click(Sender: TObject); var FS: TFileStream; Reader: TStreamReader; begin FS := TFileStream.Create('Test.txt', fmOpenRead or fmShareDenyWrite); try Reader := TStreamReader.Create(FS); try while not Reader.Eof do begin lineoftext := Reader.ReadLine(myFile); Memo1.Lines.Add(lineoftext); end; finally Reader.Free; end; finally FS.Free; end; end;

Both of my PCs at home are old Dells, running XP and Win7, and they both have BIOSes that support scheduling power events on weekdays only. So they both power up before I start a work day, and as long as I shut them down cleanly (ie, not by holding down the power button, which I do have to do sometimes) then they power up correctly on the next weekday. No weekend runs, unless I leave them powered on Friday night (for backups, etc).

Here is a response I saw on another forum with a similar question:

The only way your worker threads could be causing the UI to lag is if they are making the UI thread wait for lengthy periods of time, such as by synchronizing with the UI thread, submitting large amounts of asynchronous notifications to the UI thread, not yielding to the CPU so the UI thread gets starved for CPU time, etc. But without seeing your actual code, it is hard to say for sure why your UI is lagging. That is what the debugger is meant for.

No, it is not, because AlwaysClearFreedMemory is a compile-time {$define}, not a runtime variable (like ReportMemoryLeaksOnShutdown is, for instance). It is processed only when FastMM4.pas is being compiled. There was a feature request made 2 years ago asking for AlwaysClearFreedMemory to be configurable at runtime. It is still open: #51 Feature request regarding option "AlwaysClearFreedMemory" Then don't do such things on strings/interfaces containing sensitive data. And do use things like the CryptProtectMemory(), CryptUnprotectData(), and SecureZeroMemory() functions to secure the sensitive data in memory while you are not actively using it.

I simply mean that properly managing managed fields (strings, interfaces, variants, etc) is an important pro for using Default() vs ZeroMemory(). But, if the type has no managed fields, then it doesn't really matter which one you use, though Default() does make for cleaner code.

Maybe you meant *LESS* error prone? That is a biggy. You don't need heap allocation to get into that situation, but it is harder to do without manually coercing the type system.

The way you are using SetMenuItemInfo() and HiliteMenuItem() in the DropdownMenuShow() method will not work. You are calling them after TPopupMenu.Popup() has exited. Popup() is a blocking method, it does not exit until the popup menu has been dismissed. The TPopupMenu.OnPopup event is fired while Popup() is running. However, upon further review, OnPopup is fired BEFORE the menu is made visible, and TPopupMenu may recreate the menu AFTER OnPopup has been called and BEFORE the menu is actually shown. So, your best bet is likely to subclass the TPopupList window so you can intercept the WM_ENTERMENULOOP message, then customize your menu items at that point. For example: type TPopupListEx = class(TPopupList) protected procedure WndProc(var Message: TMessage); override; end; procedure TPopupListEx.WndProc(var Message: TMessage); begin inherited; if (Message.Msg = WM_ENTERMENULOOP) and (Message.WParam = 1) then begin // customize pmTest items as needed... end; end; initialization Popuplist.Free; //free the "default", "old" list PopupList := TPopupListEx.Create; //create the new one // The new PopupList will be freed by // finalization section of Menus unit. end.

LoadLibrary() will not return anything other than 0 on failure, so if Hinstance_Error is not 0 then checking for it is wrong. When LoadLibrary() does fail, what does GetLastError() say about WHY it failed?

By default, Indy uses OpenSSL. When that error happens, you can use the WhichFailedToLoad() function in the IdSSLOpenSSLHeaders unit to find out why. But note that Indy does not support OpenSSL 1.1.x yet, so you would have to deploy OpenSSL 1.0.2 dylibs with your app, and then tell Indy where those dylibs are located at runtime via the IdOpenSSLSetLibPath() function so it can find them. Also look at the IdOpenSSLSetCanLoadSymLinks() and IdOpenSSLSetLoadSymLinksFirst() functions to make Indy avoid loading dylibs for other non-compatible OpenSSL versions. In any case, be aware that ever since Google dropped support for OpenSSL in Android 6 in favor of BoringSSL, using OpenSSL on Android is increasingly difficult. The above MAY OR MAY NOT work, depending on the device's setup. Indy does not support BoringSSL at this time, or any of the more official higher-level Java APIs that Google wants developers to use instead of using lower-level native libraries, like OpenSSL/BoringSSL directly. The alternative is to write your own TIdSSLIOHandlerSocketBase-derived class (or find a 3rd party one) that uses whatever SSL/TLS library/API you want besides OpenSSL. For example, there is some effort in progress to add support for LibreSSL/LibTLS to Indy, though I don't think that will help you in this particular situation, but it shows that supporting alternative SSL/TLS APIs is possible.

The code you have presented does not actually use ANY real functionality from the Sockets unit AT ALL. It is actually using functionality from the WinSock unit instead. So you can just remove the Sockets unit completely, you don't have to replace it with anything. The ONLY things you need to replace are the TSocketHost and TSocketProtocol types. Those are very easy to replace, just re-define them directly in the PCConnectionHelper unit, eg: type TSocketHost = type AnsiString; TSocketProtocol = Word; Or, just drop them completely, they are not actually needed. PCConnectionHelper should just use AnsiString and Word as-is instead. That being said, I do see a number of other problems in your code, particularly in the PCConnectionHelper unit, it is using some unsafe pointer operations that can be made simpler and safer. Maybe that is causing your 64bit issue? But there are some other issues in the IBConnectionHelper unit too, most notably Ansi vs Unicode mismatches. Try these files instead: PCConnectionHelper.pas IBConnectionHelper.pas

That Sockets unit is OLD (dating back to Delphi 6) and is not maintained. That unit was Borland's (before Embarcadero owned Delphi) attempt at providing cross-platform socket classes for Kylix, but it doesn't work very well, and they decided to drop it in favor of Indy in later versions. In fact, that unit is not even distributed with Delphi anymore, XE was the last version to include it. And even if it were still distributed, the 3 class functions you mention never existed in it, not even in 2010, they were always non-static methods of the TIpSocket class, so you could never call them as standalone functions. I'm not quite sure what you are asking for, but you should not be using that Sockets unit in modern projects at all.