dummzeuch

Ouch! Wtf did they declare it public in TCustomEdit? Most not-yet-published properties of other components are declared protected. But there are exceptions there too: TCustomLabel.Caption is also public. Why? (Yes, I know, I won't get any definite answer here unless some Borland employee talked about it in the 1990s.)

Does anybody know how to prevent the ExplicitTop/Left/Width/Height properties from being written to the DFM file? I never saw any use for them and always installed Andreas Hausladen's DDevExtensions which allows to remove them. But since Andy apparently doesn't have access to the latest Delphi version there is no DDevExtensions (and also no IDE Fix Pack) for Delphi 10.4(.1) and I would like to add that functionality to GExperts. I tried, but so far failed. Any hints?

I always compile that tool with Delphi 2007. I currently can't test whether it compiles with Delphi 10.4 due a a connection problem with the license server. I have only seen that with Delphi 2007 before. It happens every time a Windows update deletes the files that the Delphi 2007 installer put into that directory. After I copied them back and everything compiled normally.

... and other older posts in this topic.

Hey, I am the German here (*1). But now you sound like one. 😉 Spoilsport! (*1: Of course I am not the only German here.)

You won't have any functionality introduced in TEdit, only the one in TCustomEdit and whatever you implement yourself in TMyEdit. That probably was obvious. 😉 If you declare the property as public, it won't show up in the Object Inspector. For that it needs to be published.

You forgot one important reason to optimize: The pure fun of it. 😉

By default the IDE enables optimization and disables Range checking and Overflow checking. I've always found that odd, because I want the best possible compiler support for debugging which means: Optimization off Range checking on Overflow checking on

I need to set a double variable in a thread safe manner. I could, of course use some synchronization object, e.g. a critical section, but on the other hand there is InterlockedExchange64, which sets the contents of a 64 bit integer variable, and a double is also 64 bits, so I thought this should also be possible in the same manner. Unfortunately that function, while described as part of the WinAPI, doesn't seem to actually be a WinAP function but implemented as a C macro in winnt.h and in assembler in Delhpi 10.2. Google found DsiInterlockedExchange64 in the OmniThreadLibrary unit DSiWin32, which implements it in assembler for Win32 and Win64. I took that code and came up with the following for atomically setting a double variable: procedure InterlockedSetDouble(var target: double; Value: double); asm {$IFDEF CPUX64} lock xchg [target], value mov rax, value {$ELSE} { -> EAX target } { ESP+4 value } PUSH EDI PUSH EBX MOV EDI, EAX MOV EBX, DWORD PTR [value] MOV ECX, DWORD PTR [value+4] @@1: LOCK CMPXCHG8B [EDI] JNZ @@1 POP EBX POP EDI {$ENDIF ~CPUX64} end; { InterlockedSetDouble } I am for now only interested in 32 bit Windows where this seems to work, but being far from an assembler expert, I wonder whether I might be missing something.

Did you test it? Since access to 32 bit aligned memory is faster, it's quite possible that the compiler generates code that aligns all parameters, regardless of size (I didn't test it either though). But the parameter target might not be aligned. That depends on what is passed into that procedure.

Maybe PasDoc?

Yes, he is correct. I had to restore those files several times after a Windows update. Not sure whether that's a Microsoft/Windows or a Borland/Codegear/Delphi 2007 problem. Are we supposed to add additional target files to the dotNet installation directory?

There were a few changes to Windows that required changes to Delphi programs but these were mostly minor and I don't remember most of them. One that comes to mind was that the known ways to prevent the screen saver from activating stopped working one after another. I think I had to change that code at least 3 times to make it work for XP, Windows 7 and then Windows 10. Then of course there was the major headache of UAC Virtualization and the corresponding entries to the manifest. But that was mostly because I did not keep up with the Delphi versions so I had to fix Delphi 2007 projects to manage these correctly. And more recently there was high DPI and scaling. Again, these could be solved at least partly by updating to the latest Delphi versions. I have no experience with dotNET, so I can't compare.

Actually there was a time (in the 1990ies) when we did exactly that: Recompile the whole VCL/RTL in our projects. Mostly because we had to fix some bugs. These bugs were fixed by Borland (Yes, there was a time where this happened quickly.), so we stopped doing that. It also became impossible to simply recompile the RTL because it required some assembler. As for components: Yes, I still compile them from sources in programs that do not use packages. I want to be sure that the source code I see while debugging is the actual source code used in the program. Given Delphi's compile speed it doesn't really matter much. But we degrees. Of course every program has its own dcu output path. Sharing that between multiple programs is a really bad idea.

Actually he wants to adjust the room lighting:

Ok, what is wrong with this: Are you sure it's not there (I think I looked it up back then, but my memory might be faulty). Or are you referring to mentioning "Borland" rather than "Embarcadero"?

There is a page in the Delphi wiki on creating packages. https://delphi.fandom.com/wiki/Creating_Packages Edit: I had totally forgotten that I wrote that page myself (many years ago). After reading through it, I must say I still like it. There isn't much I'd change today.

But we are not StackOverlfow. Thank god. I''ve got some code for calculating brightness, but this is for converting color bitmaps to grayscale. I'm not sure whether this fits your purpose because perceived brightness of a screen might be different of the brightness of a picture. type TRgbBrightnessChannelEnum = (rcbAverage, rcbFastLuminance, rcbRed, rcbGreen, rcbBlue, rcbLuminance); function GetFastLuminance(_Red, _Green, _Blue: Byte): Byte; begin Result := Round(0.299 * _Red + 0.587 * _Green + 0.114 * _Blue); end; function GetRgbLuminance(_Red, _Green, _Blue: Byte): Byte; var Hls: THlsRec; begin GetRgbHls(_Red, _Green, _Blue, Hls); {$IFDEF dzUseGraphics32} Result := Round(Hls.Luminance * HLSMAX); {$ELSE} Result := Hls.Luminance; {$ENDIF} end; function GetRgbBrightness(_Red, _Green, _Blue: Byte; _Channel: TRgbBrightnessChannelEnum): Byte; begin case _Channel of rcbAverage: Result := Round((_Red + _Green + _Blue) / 3); rcbFastLuminance: Result := GetFastLuminance(_Red, _Green, _Blue); rcbRed: Result := _Red; rcbGreen: Result := _Green; rcbBlue: Result := _Blue; else // rcbLuminance: ; {$IFDEF dzUseGraphics32} Result := Round(GetRgbLuminance(_Red, _Green, _Blue) * HLSMAX); {$ELSE} Result := GetRgbLuminance(_Red, _Green, _Blue); {$ENDIF} end; end; This is from the unit u_dzGraphicsUtils from my dzlib.

As already stated in a different thread I have adapted the TimSort implementation for FreePascal I found on github to compile with Delphi 2007 (and probably earlier, but I haven't tried it). The source code is licensed under the Apache License 2.0 and available in my dzlib on OSDN. Note that this currently only sorts an array of integer and is still pretty rough. I'm going to refine quite a bit. There seem to be only 2 (now 2.5 😉 ) TimSort implementations in Pascal / Delphi available. (According to @David Heffernan there is also one in Spring4d.), but none that does not require generics.

... or simply add the _AddRef, _Release (wasn't there a 3rd one?) methods required for an interface implementation to your ancestor class and let them do nothing.

As long as these PCs are not connected to the Internet or even the LAN, there is no need to update them, if they are "good enough". Unfortunately it is becoming difficult to buy Windows XP compatible hardware. We found only one supplier who guarantees Windows XP compatibility for his motherboards, and we had issues with the test machine we ordered with it. That's why I am currently experimenting with Windows 10 on the "embedded" PCs. I have a bad feeling about this. Windows 10 has just too much of "we are Microsoft, we know best" in it, in particular the enforced updates. I would prefer Linux, but porting the software is way too much work.

Because I have to maintain some programs that must be run and sometimes debugged under Windows XP on computers that are not or rarely connected to a LAN (so remote debugging is out). So far I have been using Windows 2007 and XE2 but I'm thinking about upgrading these projects, so the question is: How far I can upgrade? (Fun fact: I also have one active program under DOS with Borland Pascal 7 which I have been trying to get rid of for >10 years. Currently it looks like I will get rid of Windows XP before DOS.)

Given: A computer with a working Delphi 2007 installation using a Network Named User license (with the license server in the LAN). I have reached the user limit on that license. I just use too many computers in parallel at the moment and it's really annoying to have to close the IDE on one computer to be able to open it on another one. We have got enough licenses, so I thought maybe it is possible to install a different Network Named User license on that computer in addition to the existing one and for the same user. Has anybody ever tried this?

OK, I bit the bullet and tried it: It is possible to import multiple licenses into the license manager if the .slip files have different names (If you buy two licenses separately they have different names, if you buy two licenses at once, there will only be one slip file for both. Luckily we have bought them separately). I don't know yet whether assigning both licenses to the same user name will work as hoped though. The license server did not complain, but it is still possible that it won't work starting more IDEs than originally allowed because there is now an additional license for that user. EDIT: Warning, don't try this (at home or at work): There is apparently no way to remove a license with the Delphi 2007 License Manager (The one from Delphi 10.2 could do that.)

Unfortunately that's not possible in this case. There must be only one user account on these computers and it must have one specific name. (Yes, I known these are peculiar requirements, but these are no ordinary office computers either.)