Leaderboard

I don't buy that argument. People are using the software now. And software is never finished. There is always more to be done. So if you wait until it is done, then you never document it. My personal experience, and very strongly felt, is that writing documentation is a key part of finalising and debugging specification. So many times have I experienced this. Only when you write the documentation do you realise some of the issues that users will face. Deal with them before releasing and you don't have to spend as much time in back compat hell. My view is that writing documentation in a timely fashion actually saves time and resources in the long run.

New version 13.4.0 released! * TMiTeC_SMBIOS detection fixed * TMiTeC_OperatingSystem VMWare/VirtualPC/VirtualBox session identification fixed * TProcMonThread handles enumeration fixed + TProcMonThread file handle file position evaluated in handles detection * TMiTeC_TCPIP adapter detection fixed For more information about the library, download locations and documentation, see the MiTeC System Information Component Suite Home Page

Just get rid of the stupid process altogether. If someone's going to steal the software, they probably weren't going to pay for it in the first place.

Reading the stdout of the child process is a very easy way to do this.

Sure it's down to a lack of resources. But that's a consequence of expanding to new platforms. Each additional platform comes with a maintenance cost. That cost is paid for out of revenue. The bulk of the revenue comes from customers that are using the legacy platforms. If Emba continue to neglect their core business (Windows development tools) then eventually customers will look elsewhere.

CORRECT. The "time for docu work" was BEFORE THE FEATURE WAS RELEASED.

To remember when things were documented is to be old.

MiTeC Portable Executable Reader 2.1 has been released. It is based on TObject class and contains complete interface for reading executable file properties and structures. It is compatible with PE32 (Portable Executable), PE32+ (64bit), NE (Windows 3.x New Executable) and VxD (Windows 9x Virtual Device Driver) file types. .NET executables are supported too. It enumerates introduced classes, used units and forms for files compiled by Borland/CodeGear/Embarcadero compilers. It identifies numerous compilers and some installers, exe packers and protectors. Here are enumerated structures that are evaluated: DOS, File, Optional and CLR headers CLR Metadata streams Sections Directories Imports Exports Resources .NET Metadata Load Config Debug Thread Local Storage Exceptions Units Forms Packages Classes Package flags Version Info Compiler, installer and packer/protector identification PE Reader class capabilities are perfectly demonstrated by MiTeC EXE Explorer application. https://www.mitec.cz/

Sometimes your program needs to block the screen saver from automatically kicking in. My use case was that the program was recording data and whenever the screen saver was active, the data was lost (No idea why, it probably had something to do with the way HID is implemented in Windows.) So I was looking for a way to fix that without forcing the user to turn off the screen saver. The methods that used to work under Windows XP no longer work in Windows 7 and later (I don’t care about Vista), so I googled and found this question on StackOverflow. The Windows API functions PowerCreateRequest + PowerSetRequest mentioned in the highest voted answer looked promising. Unfortunately they don’t seem bo be available in Delphi read on in my blog post

Python documentation is excellent. Likewise C# documentation. And so on. Delphi is an outlier here.

I am not going to argue with you why mutable(!) global state is bad because a ton of respected people in the software development community have already proven that. As I said a singleton can be the easy solution - that does not make it a good one. Putting any code into an otherwise no or hard testable software component is only a crutch - there are ways to design software to be testable by default which does not only make it easily testable but also more robust and maintainable. Just read "Clean Code" and/or watch "Clean code talks" on Youtube. Also fwiw there is a difference between Singleton as in the GoF Singleton (ensuring that there is only one instance and preventing everyone from ever instantiating a second instance of that) and "singletoness" (establishing the contract of only having one instance but not preventing anyone from instantiating one on its own and inject it somewhere). Even in DI driven architectures there are singletons, but it is controlled via the DI system that there is only one instance being created and passed around. That decouples any consumer from the actual implementation of that singleton and makes it easily testable/mockable (see "seam")

My tests are running sometimes in parallel - and it can be done without any problems and without any special code only for testing

A fairly simple method is to pass a window handle to program2 on the command line an then have that program sent its result back in a WM_COPYDATA message to that window. Only caveat: program1 must not wait on program2 to finish in a manner that blocks message processing of the main thread.

I used on D6 ,many years ago , mdMailSlot https://torry.net/authorsmore.php?id=152 It communicated between 4 computers (programs) maid with Delphi 6. Excellent

Check the linefeeds of your source file. When you have a mix-up of CR and/or LF this might happen. Also errors when compiling show on the wrong line number and other spooky stuff...

Nevermind, looks like a developer in our office added this in the past.

Named Pipes may not be the badest decision here. See François Piette blogging about that: Inter Process Communication Using Pipes

While it is generally a good idea to avoid global variables there are cases where they can be useful, and your case is one of them. Do you know what a singleton object is? A singleton is a good solution for a scenario where you need to store some data internally in your application that you have to access from several different places in your code (different units, for instance). You place the class into a unit of its own. The unit is then used by all other units that need access to the singleton. There are different ways to implement a singleton object. The simplest one is to actually never create an instance of the class at all. Instead you use class variables and class properties to hold the data. That works well if all data you need available are simple or compiler-managed types (ordinal types, numeric types, strings). It works less well if you need more complex types, e.g. other objects. This can be handled now that Delphi has class constructors and class destructors, however. My preferred way to implement singletons is to only expose an interface type that has the necessary properties and methods to store and retrieve the data, and a factory method that returns an instance of the interface. The class implementing the interface is private to the unit (declared and implemented in its implementation section). The factory method creates an instance of the class on the first call to it and stores the interface obtained from it in a variable only visible in the unit implementation section. The unit gets a finallization section that sets the interface to nil to finally destroy the singleton.

If you think that it's related to .NET then call dcc yourself and see if that works - as I said already the error comes from the dcc. So it can only be that msbuild is passing down different values than before causing it to behave differently. To rule that out, eliminate the suspected factor from the equation, troubleshooting 101

function JsonEncodeString(const AStr: string): string; var LStr: TJSONString; begin LStr := TJSONString.Create(AStr); try Result := LStr.ToJSON; Result := Result.Substring(1, Result.Length - 2); finally LStr.Free; end; end; It expects AStr without double quotes, and returns text without double quotes. You can adjust it to your own needs. There are several options, eg with/without double quotes, encode non-ASCII chars/do not encode, etc. Probably more simple to implement the above according your needs.

Just finished a personal project for consuming and creating YAML in Delphi: https://blog.grijjy.com/2019/06/03/a-yaml-library-for-delphi/

I have made an adaptation of Pas2js for Delphi compiler. So now it's possible to compile and debug the code of this utility in Delphi IDE. If somebody interested you can find it here: https://github.com/Kryuski/pas2js-for-delphi. The original Pas2js transpiler for Free Pascal is here: http://wiki.freepascal.org/pas2js

First, this sounds like premature optimization. Yes it is 6 times slower, but you are talking about milliseconds for huge number of objects. Next, if you really need to optimize for speed, you can completely remove getter and setter methods. That is the beauty of Delphi - it does not need them at all and you can freely add getter and setter methods later on (if needed) without breaking the public API. Inline approach can solve the immediate problem, but keep in mind that inline directive is just recommendation for the compiler and under some circumstances such methods will not get inlined (though compiler will give you hint in those cases). Essentially you are writing a whole a lot of code for nothing.

I dispute that. I don't see anything wrong with a business model that concentrates on enhancing and developing their core market. Imagine what could have been achieved on Windows if all the resource that was used on the new platforms had been spent on Win32 and Win64? Remember also that the vast majority of the income is still from the Windows tools.

We have two problems: 1) REST, DBX, System.JSON duplicating JSON serialization classes. 2) Non complete docu for (1) classes. We want to keep only System.JSON with options for backward compatibility with REST, DBX. And only to develop System.JSON. When this will happen, then all demos, tests (internal), docu, must be updated to reflect the current RTL state. Now it is not the time for docu work ...