Fr0sT.Brutal

But for this the field must be of type TDateTimeField which AFAIU does not automatically happen for SQLite as the engine can't know whether an integer field is timestamp or just integer. So user has to create the field at runtime doing tricks with FieldDefs or to define it at design-time. But TC says he has dynamic queries so that's not an option

Have you tried Googling yet? https://www.google.com/search?q=vnc+delphi&ie=utf-8&oe=utf-8&client=firefox-b-ab

FDQuery.FieldByName('enterance_time').OnGetText Or try something from this topic https://en.delphipraxis.net/topic/3458-firedac-sqlite-datetime-field/

Alas, mRemoteNG uses this https://github.com/humphd/VncSharp which is not a ready-to-use library but native implementation of protocol.

So Indy is a good lib 🙂

Django, Numpy However compiled language with strict typing is always better for big projects

Try with custom TField.OnGetText.

AFAIU mRemoteNG uses some kind of component or a lib for VNC so probably there is one. Try to check that lib. But you'll likely have to write Delphi wrapper by yourself

I think any lib loading a non-system DLL should provide an option to specify the DLL path because though there are functions like SetDllDirectory you can't forbid the loading from system folders unless full path is specified when calling LoadLibrary. However SetDllDirectory allows to change search path priority to load DLL from a specific folder. Pre-loading the DLL also an option

If speed is not critical, you can determine the index of each object from inside comparer callback via IndexOf

So your program has relied on a 3rd party libs that *should* be kept up-to-date by someone else 🙂? I think in such case the program itself must control what it loads and check if a loaded module has proper version. Or just use local libs and don't bother about what's in search path.

Probably you don't have fixed revision? #386 fix from @BoIitos for a day offset bug in TIdSNTP.NTPToDateTime(). https://github.com/IndySockets/Indy/blob/master/Lib/Protocols/IdSNTP.pas

Probably depends on a country. Here Telegram is 2nd popular messenger after WA. FB and Viber etc are far less used (I know no people ever used Viber). What's good in Telegram is that it has good API suitable for rich variety of automation. At work we use it to send status messages from servers to devs' phones. I also heard about Discord or Slack also capable of such automation

SNTP just receives UTC time. Conversion to local time must be done with system functions using system's database of daylight zones. Probably you have obsolete DB

Why underlines? Just define enum items with any prefix, like encUtf8, encANSI,... Delphi strong typing won't let you use a member of another enum with the same prefix (type mismatch)

I'm against this. These prefixes just add useless noise to final code and for big libs make coder to type more chars to get proper suggestion. IOW, they could be handy for lib developer but not for those who use that lib. However, prefixing do solve name clashes.

IMHO it's much easier and more natural to register Telegram bot and send messages there.

There are even options to wrap some or even any property assignments into one container object and write something like ButtonsList.Enabled := True

And for importing/exporting data

What's the problem in 50k units?)) You can split them into sub-units each filling the same container with their personal data. You can also have pre-compiled binaries of these units to save compile time and rebuild them only when data changes. However in this case I as well suggest storing the data outside from source. I'd use resource but a simple external file also has its pro's

Universal solution is to compare working and non-working dumps line by line. If you can't use proxy, try with Wireshark

Yes, this option as well. Compiler will give lots of hints and warnings from which you can start

Actually for good clean code it's just a matter of rebuild and fix slight API changes. But years back Delphiers used too much hacks/incorrect constructions that will break and most of them come from 2 presumptions that are now invalid: - Char is 1-byte (wrong since D2009 - now it's 2 bytes) - Pointer is the same size as Integer (wrong for x64) Also using generic Delphi types for WinAPI calls instead of those specified in docs (like Cardinal instead of DWORD) was very widespread and also will cause troubles on x64. That said, I'd recommend to read advises regarding porting and do like guys said above: check availability of 3rd party components, then ensure clean code in each unit, then port to x32 app in modern Delphi, then build as x64. You'll likely have to create many test projects that use only a few of units just to test things are OK.

Yeah, probably AV considers cmd.exe as trusted so doesn't check carefully what exactly it does. You can try to run cmd once and feed commands to it via STDIN just like if they were entered in console. Use pipes for this. This sample works in console as expected: >(echo dir && echo dir) | cmd You don't even have to check STDOUT - just write to STDIN all the commands in queue. cmd will block the pipe when busy

Yes! And will it cause slowdown if you run 50 of such processes in threads? So when there are 10 threads, things do work?