Leaderboard

Agreed. Embarcadero has tied way too many things in the VCL's internals to the TApplication.MainFormOnTaskbar property, making it a do-all toggle switch to enable/disable all kinds of behaviors it was never meant to toggle. IMHO, they should never have made its scope reach more than it was originally intended for. Introducing MainFormOnTaskbar at the TApplication level was the wrong design choice to begin with, it should have been introduced at the TForm level instead (like WinForms did with its Form.ShowInTaskbar property), and NOT touch anything other than what its name suggests. But that is just my opinion...

Every time I see your name, I look forward to a long post. I honestly mean it as a compliment.

errr ... WebCore runs pas2js and translates the Delphi code into js. The "clever" part is being able to code in Delphi, not the fact that the runtime is 100% js and it can work with virtually any existing js lib you can find. What I need is someone to write a couple of classes for me in js that use another js lib, and then I want to access that lib from the Delphi language side as PODOs. The underlying library I need to use has some functions that use multi-threading to do things. I've been trying to do the multi-threading at the Delphi level, and it's just gnarly. I'd rather have a couple of classes to abstract out what I need at the Delphi level, and just let them manage things natively at the js level. There are already a bunch of popular js libs imported into the framework that can be accessed on the Delphi side. That's how things work if you want to extend WebCore the same as adding components and libs to normal Delphi.

In the JSON you want to create, "registration_ids" is an array of strings. But in your code, you are creating "registration_ids" as an array of objects instead. To get the result you want, between WriteStartArray() and WriteEndOfArray(), you need to get rid of WriteStartObject(), WritePropertyName(''), and WriteEndObject(): wrtString := TStringWriter.Create(); wrtJSON := TJsonTextWriter.Create(wrtString); try wrtJSON.Formatting := TJsonFormatting.Indented; wrtJson.WriteStartObject; wrtJson.WritePropertyName('registration_ids'); wrtJson.WriteStartArray; //wrtJson.WriteStartObject; // <-- //wrtJson.WritePropertyName(''); // <-- wrtJson.WriteValue(strToken); //wrtJson.WriteEndObject; // <-- wrtJson.WriteEndArray; wrtJson.WritePropertyName('notification'); wrtJSON.WriteStartObject; wrtJSon.WritePropertyName('title'); wrtJson.WriteValue(edtBaslik.Text); wrtJson.WritePropertyName('body'); wrtJson.WriteValue(edtMesaj.Text); wrtJSON.WriteEndObject; wrtJSON.WriteEndObject; That said, why are you using TJsonTextWriter at all? This would be much more straight-forward if you used TJSONObject and TJSONArray instead, eg: uses ..., System.JSON; var arr: TJSONArray; notif, obj: TJSONObject; strJSON: string; begin obj := TJSONObject.Create; try arr := TJSONArray.Create; try arr.Add(strToken); obj.AddPair('registration_ids', arr); except arr.Free; raise; end; notif := TJSONObject.Create; try notif.AddPair('title', 'Hi'); notif.AddPair('body', 'Notification test'); obj.AddPair('notification', notif); except notif.Free; raise; end; strJSON := obj.ToJSON; // or, obj.Format finally obj.Free; end; // use strJSON as needed... end;

The order of IDE experts is governed by the order they are added to the registry so the only way to change that order is to remove all of them and then add them back in the order you want.

What you want to do is impossible in Delphi (without bringing bad coding practice like Application.ProcessMessages in the process) You cannot have function that will return the result of some asynchronous operation. Period. Asynchronous REST request has events that will run when request is successfully or unsuccessfully finished. In those events you can add logic that needs to run as the result of the operation. procedure TMainForm.ButtonClick(Sender: TObject); begin RESTRequest.ExecuteAsync( procedure begin Memo.Lines.Add(RESTResponse.Content); end, True, True, procedure(Error: TObject) begin Memo.Lines.Add(Exception(Error).Message); end); end; Another way, by running request in task or another thread uses similar approach. In such case you would transform your function into a procedure and pass callback (procedure, method or anonymous method) that will run within thread after the request is completed. If you need to run that code in the context of the main thread you can use TThread.Synchronize or TThread.Queue

Consider me confused

While coding I didn't see you already answered. As I'm finishing coding for now I made a note about your suggestion of a modified HMAC implementation which doesn't trigger overflows. And yes, turning of the checks should always be a last ressort! That's why I was asking. About your protect buffer points: I did sort of inherit this DEC library and thought it's too good to let it die, but I'm no really expert in these things. I learned quite a few things along already though. I will look at removing those, you might be right. I just didn't want to remove something not causing me real trouble from an inherited library when I don't completely understand the implications/effects this creates. That's also the thing with ReallocMemory. I never really understood its purpose and when I asked a few months ago in German DP because of some C++ Builder compatibility issues I didn't get really useful pointers why this might be used here. I only got some vague C++ Builder compatibility information as answers. So I left as is. But we can remove this as well. Just clearing the memory somehow at some point might reduce attack surface a bit. Yes, if the attacker can slow down that process well enough to be able to have enough time to read out memory while it runs that protection will not help. It just helps not having possibly sensible information lying around for longer than necessary.

If you were in my employ I'd fire you for doing something like that. What happens when a bug in your code causes your license check to fail and you execute corrupted code that wipes the customers disk?