omnibrain

Ah, did not know that. Is there a way to convert our 100+ existing DFMs?

Are there any (known) changes to the compiler regarding string handling from Delphi 10.2 (or 11.0)to 11.2? I don't have code, because I can't reproduce it yet, it's more of a feeling, that something is wrong. We do a lot of serial communication. Parts of the code are rather old, but survived man Delphi version changes. Some of the code may be pre-Unicode but got modernized before my time and thus before source control, so I can't check the history. We read the ansichars that come via the serial connection and put them into chars and them into strings and work from there. I think that's not ideal because strings are unicode (nowadays) but so far it worked fine. Recently we switched from Delphi 10.2 to 11.2 (with a short stint in 11.0, but I'm only 80% sure the error wasn't there). And now it only works like 99.9% of the time. (With our test systems everything works, but our customers have more "traffic). The error is, that we get symbols we can't explain in positions where they don't belong. It looks like chars get converted to other hex values. At the moment I'm just poking around, because the error is rare enough and we don't have a trace yet. But perhaps someone knows of a possible change to string/char handling with the most recent compiler versions.

Sure, but coming from Java and .Net it's just a basic language feature missing. Maybe it's easier to implement if everything runs in a VM...

As suspected unsave byte/char handling. We converted the offending parts to TByte now. But it was also a problem because the code expected a byte converting to an integer value, but the message could have had legit anything else at this point. The trigger was an unusual message. Once we had a trace we could recreate it with our test hardware and it was obvious. The exception was many calls deep into the processing code and got only caught on the top of the call stack so we would have probably taken a few more days to really find this part. Perhaps we should add something like MadExcept. It's a shame that Delphi offers no inbuilt StackTrace at runtime.

Good news everybody, we got a trace and it looks like we can provoke this issue with our test hardware.

They should keep their "value". It could for example be the "length field" and $A9 for the 3rd byte/char received would mean that we have to work with the next 169 characters, the 171st char/byte received would then be a checksum over all bytes/chars received, which could be $F3 for example. It could very well be that it has been broken forever, but we processed millions of "messages" per month and never had this problem. But like I said, I can't totally rule out, that we just never received such a message before. It could be just a single character causing this trouble by getting converted and only in few positions it would cause (visible) trouble. Today we traced all the "messages" at a customer, but of course it did not happen. Tomorrow I'm going to add additional logging code, so we pinpoint closer where the exception happens and then we should know what the "wrong data" is.

The value can be basically anything from $01 to $ff. It's serial communication with various protocols. Some text based, some byte based and some of them a mix of both. Some of them are delimited by EOT ($04), for some we need to calculate the lengths, for some we need to calculate CRCs, etc. Not all in the same process, but the pattern ist the same for all of them and the tfr_com.dataavail ist the same. The serial communications components provides ansichars. And we don't expect to receive multi byte characters via serial communications anyway. We communicate with old hardware, with old protocols. Most of the time there is no encoding specified, but for the text parts (if there are some) most of the times just plain ascii characters are used.

I tried to condense the code: procedure tfr_com.dataavail(sender:TObject; Count:integer); var i : word; c : char; // serielles zeichen empfangen ac : ansichar; s : string; begin for i:=1 to count do if com.ReadChar(ac) then begin c:=char(ac); {$R-} showinchar(c); if assigned(receivecharproc) then receivecharproc(c); {$R+} end; end; //receivecharproc is procedure tfi_m.receivechar(ach:char); begin //state machine that works with the chars to parse the various protocols and adds them to a string typed variable for further processing end; ReadChar provides us ansichars, so I guess it's easiest just to stay with ansichars for further processing. But why did it work for 10 years and suddenly stopped? I can't rule out, that we see a new type of input we haven't seen before. But I still have no trace of what we actually receive...

Are you going to put it on github?

Yeah, me neither. That's why I ask in general terms. Like if someone asked if anything with pointers and DLLs has changed in the latest release. Then we would answer "of course, ASLR and HE-ASLR is enabled by default. Look into the linker options." I hope for something like that. I suspect the code has been broken since the unicode migration and now some (undefined?) behaviour in edge cases may have changed. I'm afraid I won't be able to avoid reworking it, into proper datatypes for stuff received via serial connection. (A proper mix between raw byte protocols, text protocols and protocols that mix both). The discussion in Best type for data buffer: TBytes, RawByteString, String, AnsiString, ... - Algorithms, Data Structures and Class Design - Delphi-PRAXiS [en] (delphipraxis.net) goes into a similar direction, thoguh starting at another angle.

"transliteration" is a good word. My gut feeling is, that we receive some byte value that translates to a char, that get's "transliteraded" to a unicode glyph and when we try to work with the byte value again we get the value of the unicode glyph. Yes, I'm currently thinking about converting everything to ansichars and ansistrings, or even rawbytestrings, or possible TBytes (though we depend heavily on pos() for protocol parsing). But it may very well be, that I'm chasing ghosts. So if someone could chime up and say "yes, something really changed", that would give me confidence. ?

Can you show a bit more code? How do you setup the stream? Perhaps you need to (re)set the position of the stream to 0 before sending.

With Delphi 11.2 every so often when opening a project, or opening another unit when having a project open my IDE hangs. It's always a different code file, but the symptoms are always the same. "CodeInsight: Loading project [...]" stops moving and the IDE just sits there, consuming 0% CPU and a varying amount of RAM. Only thing I can do is to kill Delphi via the Task Manager. Our projects can be quite large, with lots of units. I also use MMC, GExperts and DDevTools in their latest incarnations. Are there any likely cuprits? Anything I could do?

Thanks, but it looks like that the classic version is gone from 11.2.

bds.exe is just idly communicating back and forth with the DB server, the DB components use at design time. DelphiLsp.exe (all 3 processes) does nothing. Even if I kill those processes Delphi stays stuck. 😞

I ran into a problem, that the debugger (in 11.2) does not seem to understand if you use the same name in tow places within one function. case geocoder of gc_pos: begin //... var lat:=posdata.data[0].latitude; var long:=posdata.data[0].longitude; //... end; gc_nom: begin //.. var lat:=position.lat; var long:=position.lon; //.. end; //... end; When debugging into the gc_nom case the debugger showed me uninitialised values ever after the assignement.

I threw together a simple file serving THttpServer to host some local data (mainly static JSON to emulate some APIs). But now I need to add a "Access-Control-Allow-Origin: *" header. Where would I do this. My server code is literally not more than: HttpServer1.DocDir:='C:\temp; HttpServer1.Port:='16010'; HttpServer1.Addr:='127.0.0.1'; HttpServer1.Start(); I tried to add an "OnBeforeAnswer"-Handler, but I'm totally lost. procedure Tffileserver.HttpServer1BeforeAnswer(Sender, Client: TObject); begin var lclient:=THttpConnection(client); lclient.SendHeader('Access-Control-Allow-Origin: *'); end;

How should I have known? I figured it out in the end, so it wasn't too difficult after all... I understand. That totally makes sense.

You might have misunderstood me. I did not use "SendHeader" by myself. I just initialised PersistentHeader:='Access-Control-Allow-Origin: *' before starting the server. Then I wondered why my browser hung accessing the served files and why Postman chocked on the headers. So I debugged into the "SendHeader" function and saw there, that it loses the second CRLF at the end of the header when adding the PersistentHeader. I guess that leads to a missing blank line between header and body, but I did not go that low level while debugging. My workaround is to add a CRLF to the end of the PersistentHeader when I set it in my Program. But I think (at least from an UX standpoint) that should not be necessary.

I found something I overlooked earlier: The PersistentHeader property might be useful. But there might be a bug in THttpConnection.SendHeader. I looks like, that in adding the PersistentHeader the second #$d#$a at the end of the headers might gets omitted. That means, that the blank line between headers and body is missing.

I don't use any of them. I use the "automatic serving of the contents of the DocDir" method. So I think I would have to use the events, I guess. But where can I add a custom header to the automatic response? Do I need to create my derived "myHttpConnection" class and override "ProcessGet"?

Tsilang is horrible, horrible, horrible for source control. It stores the translation data in a blob within the DFM. I don't know the other tools, but I would take a sharp look at how they store their translation data.

And if I install 11.2 now, I have still to install the patch and do the fix, because there is no updated install file?

My Understanding is, that App passwords also will stop working: Office 365 App passwords | Blog | Limilabs I tried to jump through a lot of hoops and use OAuth with Clever Internet Components, but it all lead to errors, but I might try again, because: I tried the TMS FNC Cloud Outlook Mail component, but you can only read and send mail. I also need to delete or at least move mail. Has someone found another component? I don't have the time to implement and maintain the Graph API by myself.

But when you are only a handful of trusted contributors you don't have to use the Github workflow but can have them merging (perhaps with rebase and smashing) locally and then have them push the changed branches to Github. And if you work this way with your trusted contributors you can still be open for external contributors with the Github Fork-Merge-Request-Workflow. That's really the best of both worlds. We have to face, that Delphi itself is obscure enough for younger developers. Clinging to outdated tools, hosting options and workflows nobody learns anymore isn't going to help.