Leaderboard

If the error just could be reproduced here in my environment, I would do. Nevertheless, I will add madExcept in the next release.

The stucture relates to the class and its methods as seen in the tree view to the left. F.i. if only the order of methods in a class changes, be it in the interface or the implementation, the structured difference would rate that as equal. Inside each method the diff is the same as a simple line diff.

Try Graphics32: Use a TBitmap32 with a memory backend (instead of a GDI backend) and display it with a TImage32/TImgView32 control. That of course requires that the bitmap is 32-bit or that it's feasible to convert it to 32-bit in order to display it.

https://developer.apple.com/xcode-cloud/ You'll still need a Mac, but you don't need to own every Apple device.

Hard to say for sure without seeing the complete FTP sessions, but if I had to guess, the command connection in TIdFTP is likely being dropped part-way through the transfer, which would explain why the final response is not being received, and also why sending a QUIT request after the transfer timeout is causing a RST packet. Are you performing these transfers through a router/proxy/firewall, by chance? If so, they tend to drop idle connections after a few minutes, and thus are likely dropping the command connection during a large transfer since the command connection is sitting idle while the transfer is in progress. TIdFTP has a NATKeepAlive property to help avoid that issue, try enabling and configuring it as needed. You should filter the logs to isolate just the FTP command connections before saving them. You don't need 500Mb to show a handful of packets.

Yes! On phone work too Thanks for help Lars Fosdal

what happens if you replace MYBOOL with bool and PRICER_DEVEX and PRICER_STEEPSTEDGE with plain integer constants (eg 2 or 3 or 4....) ? If you get the same problem then this would be a more helpful form to post your problem source code (since your quoted code does not include definitions of these block capital items). Or, if it starts working, can you include the definitions we need to get the code to be like yours (in this case it could be that MYBOOL is being defined differently in the debug and release compilations for example....)

It is valid alert. You need to initialize out parameters before they are used. Only managed out types will be automatically initialized. When you mark parameter as out, you are saying I will properly initialize that variable (setting to nil is also proper initialization in this context) If you don't initialize that parameter inside the method, then this is a bug and your method signature is telling a lie. If you want to initialize variables outside the method, then you should use var parameter. The fact that Delphi automatically initializes only managed out types, is just implementation detail of the compiler. In theory it is behavior that may change, most likely it will not, but out parameter is meant for output, compiler is free to discard its value in the function prologue.

type TJobflag = (jfstart, jfAdd, jfLoaded, jfDone); Tcompareflag = (cfCaps, cfDupes); Jobs = set of TJobflag; Compares = set of Tcompareflag; function AddItems2(const aArray: array of string; var aList: TStrings; aCompareSet: Compares) : TJobflag; var jobSpecification: Tcompareflag; S: string; RC: Boolean; begin result := jfDone; RC := False; for S in aArray do begin for jobSpecification in aCompareSet do begin RC := (jobSpecification = cfCaps) // and // compare S for Caps; RC := RC or (jobSpecification = cfDupes) //and dupes found If RC then begin if not assigned(aList) then aList := TStringList.create aList.add(S); end; end; result := jfLoaded; end; end; try if AddItems2(['Hello', 'World'],lst, [cfCaps]) = jfLoaded then Writeln('True') else Writeln('False'); if lst <> nil then Writeln(lst.Text); finally { uncommenting this will raise an invalid pointer exception later } // lst.Free; end; Or procedure loadLists aList := TStringList.create result := jfDone; for S in aArray do begin for jobSpecification in aCompareSet do begin RC := (jobSpecification = cfCaps // and // compare S for Caps; RC := RC or (jobSpecification = cfDupes) //and dupes found If RC then aList.add(S); If RC then jobStatus := jfLoaded; end; end; end; // future Procedure processLists Abover my spin on it use enums to determine status testing for list = nil does not tell if list need was ever tested.

Pascal Analyzer is trying to tell you: "Your method misses to initialize aList before entering the loop, because in case the loop is empty or condition is always false you end up with an uninitialized out parameter aList!" So, yes, it is a valid alert and although you may get away with it in most cases, it may fire back sometimes. It should be possible to create a use case where it fails.