Uwe Raabe

Perhaps a UniqueString(s) before unloading the package might work then? It looks like the problem comes from the package invalidating the result string memory when unloading. The tricky part now is to find a workaround for this.

Can you try assigning the string constant to a variable first and/or calling UniqueString on result after assignment? The string literal may vanish when unloading the package.

Even without an active subscription one can request a bump for the installation counter. It has just to be requested from sales instead of support.

Could it be that using the equality operator qualifies for calling any method?

Perhaps when you ask which image shows valid Delphi code.

@Patrick PREMARTIN I have never seen some documentation about a REST API to forbit or even avoid POST requests. If you have a link to such docs I would be interested. In my (surely limited) experience with REST API implementations that are not simply read-only, I never encountered anything restricted to GET requests.

You can use a TRESTResponseDataSetAdapter and connect its Response property to your TRESTResponse instance (alternatively use a TRESTResponseJSON instance to provide a TJSONObject). Iterating through the records list and adding each tubes items to your dataset may need some additional coding around, though.

The above JSON has an array "records", where each item contains a "coin_mech" object, which itself contains the "tubes" array. Are you interested in the "tubes" from one specific "records" item or do you want to collect all "tubes" arrays from all "records" items.

Which Delphi version are you using?

IMHO the best way ist to use a dedicated class handling the parameters and place that in body: type TMyParam = class private FUserName: string; FSecret: string; FShortcode: string; FMsisdn: string; FMessage: string; public property Message: string read FMessage write FMessage; property Msisdn: string read FMsisdn write FMsisdn; property Secret: string read FSecret write FSecret; property Shortcode: string read FShortcode write FShortcode; property UserName: string read FUserName write FUserName; end; ... var myParam := TMyParam.Create; try myParam.UserName := 'email@email.com'; myParam.Secret :='password'; myParam.Shortcode := 'pacific bulkms'; myParam.Msisdn := '6799998122'; myParam.Message := 'Hello World'; RestRequest1.AddBody(myParam); finally myParam.Free; end;

May be I missed it, but I cannot see where you set RESTRequest1..Method to rmPost (the default is rmGet). The default parameter kind is pkGetOrPost, which put the parameters in the URL for GET and into the body for POST. This would explain the "Empty Request..." error.

So you are out for a warning/hint when abbreviations are used? (I won't consider error as long as CTRL-O-O actually follows such a setting) You might consider to rephrase the description as it isn't clear IMHO.

It is not clear to me what this issue is about. Currently you can use the abbreviated version as well as the verbose one. I don't see where hint/warning/error settings come into play here, besides the directives affecting them.

The problem in your code is that the anonymous method calling RunWork uses the counter variable directly. While it is correct that this variable is captured for the anonymous method, it is captured by its address and not by its value. Therefore the RunWork call uses the value of counter that is given in the moment of that call. Usually that is different from what you expect. You can solve this by injecting a method returning the anonymous method with the counter value at that time. function MakeRunWork(ACounter: Integer): TProc; begin Result := procedure begin RunWork(ACounter); end; end; procedure TForm780.Button1Click(Sender: TObject); const NumberOfParts = 1; var counter: integer; TaskArray: array of iTask; begin { --- run button --- } SetLength(TaskArray, NumberOfParts); for counter := 0 to NumberOfParts - 1 do begin try TaskArray[counter] := TTask.Run(MakeRunWork(counter)); except on E:EAggregateException do ShowMessage( E.ToString); end; // try end; // for counter end;

I don't understand how this can even work at all. If PosY equals Y - 1 then PosY cannot be equal to Y - 2 nor Y - 3 and so on. There can either one condition be met or none, but not all.

@David Heffernan, that was my first idea, too. There is just some code missing that handles the BytesRead > 0 case before the loop exits. Some if-then after the read cannot be avoided in this case.

I cannot see any compile error shown in the original post either. There is only one reference which doesn't make any sense:

One can also use the csUpdating flag in ComponentState, which is controlled by the Updating and Updated methods. It works for all TComponent descendants. But now we are in a much wider realm than the original OnClick problem describes.

Simply setting FState doesn't reflect the change in the control while its handle is allocated. That may work for some initialization during FormCreate before the handle allocated, but is no general solution.

That is actually what my build server (resp. FinalBuilder) does here. That is only one reason, why I avoid creating any exe on my development system and send it to a customer. I would love to see a reliable solution in the IDE itself. For compatibility reasons I suggest to add a special entry to the configuration combo which handles the storage in the base configuration and clear all child configurations. One has to remember that the version info dialog for Win32/Win64 only projects differs from those targeting other platforms, too. The former can handle that in the base configuration, while the latter has to do it in the platform bases. The reason is that different platforms follow different rules.

Sadly, that exactly hits the point. Joe Hecht passed away some time ago.

It affects all TButtonControl descendants of which TCheckBox is just one. The easiest way to avoid that is to use actions. Another way would be to make use of the (protected) ClicksDisabled property, which skips the call to the event handler. That is basically the same as what the actions do.

Project Magician follows a different scheme: It has an option to remove all child entries so that only the base values are effective. Unfortunately it doesn't force you to change base values only nor does it warn if you don't.

This can be easily solved by converting to string before calling the constructor: JSonObject.AddPair('Test', TJSONNumber.Create(High(UInt64).ToString)); // add System.SysUtils to uses clause If the UINT64 value is already correct in the JSON string it is properly converted to an UNIT64 later.

I'm sorry, but I have no clue what you are talking about.