dummzeuch

If automatically updating the project (by loading it into the Delphi 10.3 IDE) fails, your best bet is to create a new VCL project and add all units from the original project to it. Then copy all the settings (especially the search path) from the Delphi 2007 project to the new project and fix any problems afterwards. Make sure you retain a copy of the original project so you can always look up any settings. I hope yon still have got Delph 2007 around? Otherwise it might be a bit inconvenient. You do have updated versions of all your 3rd party components or at least their source code, do you? Otherwise you are out of luck. Note that in Delphi 2007 there was no such thing as a base configuration but only one configuration for Debug and one for Release builds. You might want to figure out which settings you want to move to the base configuration an which ones to keep in Debug / Release configurations. Another option, if feasible, might be to upgrade the project through several intermediate Delphi versions since they usually can work well with projects from their immediate predecessor. That would of course require installations of several intermediate Delphi versions, which I don't know if you have them.

Just in case we are not the only ones still using Samba with an NT domain: Windows Update KB5028166 which will automatically be installed on Windows 10 today, breaks compatibility with that domain type. After the installation, a login with a domain account no longer works. Removing that update fixes the issue, but of course that’s no permanent solution.

I wonder whether the Unit Dependency graph in PasDoc or the Project Dependencies expert in GExperts might be of any help here. They both contain the required information, but possibly not in a helpful format. Maybe they could be improved to become more helpful.

There is already a patch to fix the issue. Thanks a lot @StefanMetzmacher

It has reached the Samba mailing list and there is a bug report for it. If understand it correctly, Microsoft did not document the changed behaviour beforehand, as apparently they promised they would. (Microsoft was actually contributing to Samba for a while, not sure about that recently.)

Yes, we should have been updating it years ago. As I said, there are reasons. But I won't discuss them here. The point simply is that it stopped working due to an update that was forced on us without a warning (at least not one I noticed). I have been spending several hours already to uninstall and block this update so my colleagues can finally get their work done. Large companies and home users will most likely never notice because even home users who use SMBv1 will most likely not use an NT domain and accessing a stand alone Samba server still works.

I'm not alone and it's spreading: After update KB5028166 trust relationship broken. KB5028166 update. computers are unable to join the domain. So there is hope that somebody figures out a fix or a workaround. In the meantime nearly 20 of our computers were affected. My warning not to install this update came to late for several of my colleagues.

That problem consistently occurred on all our computers when that update was installed (5 so far, 2 of those VMs) and disappeared when I uninstalled it. And I'm not the only one who has that problem. No idea why it works for you.

I guess going back to the feature set of Turbo Pascal 3 would also improve the stability of the IDE and the compile speed [/sarcasm]

There is the "Convert Strings", editor expert which allows for more complex conversions.

I'm mostly a Delphi programmer, I have no experience with C++ (or Java or C#) and only used C many (>20) years ago, so please forgive me if I ask stupid questions. I am currently struggling to write some C++ code to use a 3rd party library that's written in C++. Given a buffer pointed to by zMap containing float values, how do I convert these values to strings? I know that these values are between 1 and 3 with the odd inf sprinkled in, because I have dumped the memory to a file and read it in Delphi as Single. (And also because these values are supposed to be a distance in that range.) This is what I tried to output the first value: float* zMap = SomeFunctionThatReturnsABuffer(); char buffer[100]; snprintf(buffer, sizeof(buffer), "%f", *zMap); cout << buffer << " " << endl; I got a large number (>1000), even though I know that the values are between 1 and 3. If I use the same code on an array like this: float Arr[3] = {1.1, 2.1, 2.5}; float* Ptr = Arr; char buffer[100]; snprintf(buffer, sizeof(buffer), "%f", *Ptr); cout << buffer << " " << endl; It works as expected. What am I missing here?

Turns out I didn't check carefully enough. There actually are values in that array that are much too large, and these values show up in the Delphi dump as well. So: There was nothing wrong with the C++ code, just me being stupid. Sorry about that. I still have no idea where these values come from. Maybe the algorithm that calculates them is flawed.

I had some curious bug today with the following code: procedure ReadHeader(out _w, _h, _Depth: Integer); const PGM_Magic_Number = 'P5'; var s: string; begin s := ReadChar + ReadChar; if s <> PGM_Magic_Number then raise ESigError.Create(_('File is not a valid PGM file:') + ' ' + _fn); // more code here end; Which failed the test even though the first call to ReadChar returns 'P' and the second returns '5' (I stepped through it in the debugger) so s should have been 'P5', but the actual value of s was '5P'. Apparently Delphi created code that called the second ReadChar before the first. But why? Maybe because it fills the parameters for the function System._UStrCat3, that it apparently calls to do the concatenation, from right to left? So I changed the code like this: procedure ReadHeader(out _w, _h, _Depth: Integer); const PGM_Magic_Number = 'P5'; var s: string; begin s := ReadChar; s := s + ReadChar; if s <> PGM_Magic_Number then raise ESigError.Create(_('File is not a valid PGM file:') + ' ' + _fn); // more code here end; and it works now.

Now that you mention it: There was some Unicode stuff involved somewhere else in the unit (type casts from AnsiChar to Char), so it can't have been Delphi 2007 ... Must have been Delphi 10.2 then. (Sorry, I have been trying to get somebody competent at Deutsche Telekom on the phone for the last 2 hours. This is getting on my nerves and wreaking havoc with my concentration.)

No idea. Maybe we are using different Delphi versions (mine is Delphi 2007 in this case) or compiler settings (trying to compare those would open a can of worms).

Does anybody know about (preferably free) Delphi code for reading a .ply (Polygon) file? I'm most interested in the binary format but if the code can also handle the text format that would be a plus. I'm about to write this myself but I don't want to reinvent the wheel.

Wikipedia says otherwise: https://en.wikipedia.org/wiki/PLY_(file_format) "There are two versions of the file format, one in ASCII, the other in binary."

Which C library?

Sorry for the confusion, I got distracted when I wrote that post. That source code was just for showing that ReadChar2 is called first. I have now added an explanation to that post.

A simple test case would be this: function ReadChar1: Char: begin Result := 'P'; end; function ReadChar2: Char: begin Result := '5'; end; procedure ReadHeader(out _w, _h, _Depth: Integer); const PGM_Magic_Number = 'P5'; var s: string; begin s := ReadChar1 + ReadChar2; if s <> PGM_Magic_Number then raise ESigError.Create(_('File is not a valid PGM file:') + ' ' + _fn); // more code here end; Edit: I forgot to add for what this is a test case. It's for stepping through with the debugger. Since ReadChar1 and ReadChar2 are two different functions, it's clear in which order they are executed. It's ReadChar2 first and ReadChar1 second.

This looks promising: https://sourceforge.net/p/glscene/code/HEAD/tree/trunk/Source/GLS.FilePLY.pas Thanks Edit: This seems to only read PLY files in text format.

You could simply use Notepad++ to change the line break to Unix and back to Windows. That fixes any of these problems. Also Delphi 11 comes with a setting to do that automatically: Tools -> Options -> User Interface -> Editor -> Line Endings: "Convert files with known extensions to CRLF" (No idea when that was introduced. I had not noticed before. Also no idea whether it actually works.)

They will just introduce a new API and deprecate the old one. Happened before, will happen again.

There are usually some tasks that do not need to run on the performance cores, so setting the affinity mask for the whole program may not be the best strategy, even though it's the easiest way. But I'm sure that sooner or later Windows will start ignoring those masks because everybody sets them. Of course this is currently the only way to do that for threads generated using parallel for.

I have inherited this code from a program originally written in Borland Pascal for DOS, which I have adapted to Delphi 32 Bit: function BuildDigits(_Digits: UInt16; _Invalids: UInt8): UInt16; var TempInt: Int16; begin TempInt := _Digits; Dec(TempInt, 2048); TempInt := TempInt * 11; TempInt := (TempInt and $FFFC) or (_Invalids and $03); // <-- crashes here TempInt := Swap16(TempInt); Move(TempInt, Result, SizeOf(Result)); end; The adaptations were to change variable declarations: Word -> UInt16, Byte -> UInt8, Integer -> Int16 (Integer was 16 bits in Borland Pascal). Only Integer -> Int16 was really necessary, the others were just to confuse^d^d^d^d^d^d^d^d^d^dclarify the code. (The function Swap16 swaps the bytes of a 16 bit value, so $1234 becomes $3412.) The code works fine if range checking is turned off {$R-}. But with range checking turned on {$R+}, it fails for e.g. _Digits = 0, because a range check error occurs in the line marked above. Edit: The line the crash occurred was not the one multiplying with 11 but the one below. I would like to be able to keep range checking enabled in debug mode, so how can I modify the code to return the same results as if range checking was disabled? My idea was to change TempInt to an Int32 but I am unsure how to proceed. (I'm getting old. I'm sure this wouldn't have posed a problem for me 10 years ago. Or maybe it's the heat and not enough sleep.)