Leaderboard

Out params in Delphi kinda suck because the compiler does nothing to enforce out semantics. Compare and contrast with C#.

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.

VMware users, patch now! https://www.bleepingcomputer.com/news/security/attackers-are-scanning-for-vulnerable-vmware-servers-patch-now/

https://google-developer-training.github.io/android-developer-phone-sms-course/Lesson 2/2_p_sending_sms_messages.html Has SMS access been enabled for the app in the Android settings? Also, best practices: https://stackoverflow.com/questions/32814922/why-does-android-ignore-read-sms-permission

Yes and no, I mean "out" is giving back a fresh variable to its caller. The state before should be considered undefined, it can exist, can have values, can be nil. I would say that in the 1. line inside the method, this does not exist, since the out parameter shall give back a new parameter. Whatever it was before shall not matter. From my opinion this is what "out" should originally stands for, even if it maybe can be misused somehow. On the other side, "var" brings in an existing parameter, inside the method, which can be used or changed at will.

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.

Problem solved, after a bit of googling. Need to set the following item in the Entitlements List of Project Options to true for sandbox applications using TOpenDialog: "Read/write access to files selected with the Open or Save"

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.

I find it very convenient to have a common _Transfer\ folder, which is available on the host, and shared in all VM's. This helps to easily share files and data between the different VM's. Thos files were stored on the host, and in the VM's they were only virtually binded. Of course this is not intended to be opend for write from several VM's or the host at the same time, but just for manual exchange (e.g. for PAServer files, etc).