Andrew Spencer

Many thanks Angus and Francois, for this, and for your work on ICS. Very much appreciated!

I have my simple TIcsMQTTClient-based app working on Windows in a test console application, using the above advice. Instead of using FMQTTCli.LinkSocket.MessageLoop which is blocking, I call the following procedure, which could allow future expansion and better control procedure RunMessageLoop; var Msg: TMsg; begin while GetMessage(Msg, 0, 0, 0) do begin TranslateMessage(Msg); DispatchMessage(Msg); end; end; My main problem now is that I need to get this running on both Windows and Linux platforms, and I see that ICS does not (yet?) support Linux. (I thought that FMX meant Linux support, and did not read the fine print!) Any suggestions?

Thanks, both of you. I think that I'm getting the idea of the differences between GUI and console. I've added FMQTTCli.LinkSocket.MessageLoop; To get through the async events, with a FMQTTCli.LinkSocket.PostQuitMessage; to terminate the handling (in the OnOnline event). Since I'm aiming to write an application with API handling and writing MQTT subscriptions into a database, I can see that threads are likely going to be needed sooner rather than later!

Thank you. I have done that, with minor success, using Mosquitto under Docker. On running my simple console application, the TIcsMQTTClient.OnEnableChange gets launched, when expected. I'm unable to get any further events triggering in my console application (attached) although a GUI application (based on the ICS example) works fine. If anyone could try out my source code, and find the problem, it would be very much appreciated! MQTT_Subscriber_Console.zip

I need to use TIcsMQTTClient in a console app (for use in Windows or Linux) I'm battling with the event handling, which seems not to be passing parameters correctly. My initialization code is dynMQTTClient := TIcsMQTTClient.Create(nil); dynMQTTClient.Name := 'dynMQTTClient'; enableMethod.pMethod := @MQTTClientEnableChange; enableMethod.pObject := nil; dynMQTTClient.OnEnableChange := TNotifyEvent(enableMethod); onlineMethod.pMethod := @MQTTClientOnline; onlineMethod.pObject := nil; dynMQTTClient.OnOnline := TNotifyEvent(onlineMethod); messageMethod.pMethod := @MQTTClientMsg; messageMethod.pObject := nil; dynMQTTClient.OnMsg := TMQTTMsgEvent(messageMethod); where each of the xxxxxMethod records is TMethodPointer = packed record pMethod: Pointer; pObject: TObject; end; My handlers are then procedure MQTTClientOnline(Sender: TObject); procedure MQTTClientMsg(Sender: TObject; aTopic: UTF8String; const aMessage: AnsiString; aQos: TMQTTQOSType; aRetained: Boolean); procedure MQTTClientEnableChange(Sender: TObject); But the parameters, when examined inside the routine, are "wrong". e.g. Sender is nil when these events are launched. (I have successfully used the above code method with TTimer and TRESTRequest events) Any ideas/suggestions as to what I might be doing incorrectly?

At last! Some respite from the many years of wandering toolbars. Thank you for this welcome addition to great utility. A minor request: Since the various GExpert Configuration dialogs are resizeable, would it be possible, in a future revision, to "remember" the size (always ensuring that they are never taller/wider than the current screen size, of course)?

Answering my own questions... The line should have been Text := Format('%.*f', [TfrmMain.qMyTable.FieldByName('decimals').AsInteger, Extended(Sender.Value)]);

I get the feeling that qMyTable is no longer in scope when this event is launched

I have a table with a float field, and would like to format the decimal places displayed for this value based on the content of another (integer) field in the same record. Access is via a TFDQuery. I tried to hook the OnGetText event of the float field in question with the following code, but this is giving an access violation error. procedure TfrmMain.ItemValueFormat(Sender: TField; var Text: String; DisplayText: Boolean); begin Text := Format('%.*f', [qMyTable.FieldByName('decimals').AsInteger, Sender.Value]); end; If anyone has tried something like this before, I'd appreciate some tips/code snippets. Thanks!

Excellent - thank you - that did exactly what I was looking for.

Hi Somehow in the update to Delphi 12.2, I have lost the Windows icons associated with the various Delphi file extensions (.pas, .dfm, .dpr, .dproj etc) Is there any easy/quick way to get these back?

I narrowed it down to Jedi Component Library. The same 3rd party installation also appeared to give the same IDE closing error with Delphi 11.3

Using Delphi 11.3 I often have a situation where the .Visible property of a control depends on the .Checked property of a TCheckBox (or similar). To do this, I typically write an OnClick event for the TCheckBox, and set the .Visible property of the target control in a single line of code e.g. TargetLabel.Visible := SourceCheckBox.Checked; I also make sure to call this OnClick event at startup, if I happen to need to load the .Checked state from a previously-saved registry or Ini file entry. I thought that LiveBindings was designed to help me get rid of needing to write OnClick events. So to test I set up a TForm with a TLabel and a TCheckBox, with LiveBindings Designer as follows: My expectation was that, from then on, the TLabel.Visible property will simply follow the state of the TCheckBox.Checked property. No additional code would need to be written. BUT, it didn't work exactly as I expected. Question 1 : When I run this, the TCheckBox.Checked property initialises to the Design-time setting of TLabel.Visible. Setting TCheckBox.Checked to True at Design-time is ignored. Why is it not the other way around i.e. The TCheckBox.Checked value, at Design-time, determines the TLabel.Visible property at Run-time? That's the way that the arrow is pointing. This only appears to happen AFTER the application is up and running i.e. clicking on the TCheckBox will alter the visibility of the TLabel accordingly. Question 2 : How can I get this initialised, at run-time, so that the two controls start off operating correctly? I have only found that setting BOTH the TCheckBox.Checked AND the TLabel.Visible properties to the same value gets things going correctly. Question 3 : Programatically changing the TCheckBox.Checked state at runtime does not cause the TLabel.Visible property to change. Question 4 : Have I just totally misunderstood what I can do with LiveBindings, or how to implement what I want?

I've often used a derived class on TCustomControl to access a control's Canvas property. type TGetCanvas = Class(TCustomControl); and then used it later in a line similar to this: TGetCanvas(progressPanel).Canvas.TextWidth("Hello World") In trying to neaten things up, I noticed that the same type declaration was in the interface or implementation section of numerous units. I tried moving the declaration to the interface section of a "library" unit, and useing that unit in all these other units. On compilation, however, a line like the one above would raise and error "E2362 Cannot access protected symbol TCustomControl.Canvas". Why is this not functioning in the same way as if the type declaration was in the unit itself?

Ouch! OK - that makes sense. I'll have to do a work-around for how I want it to behave. Thanks, Uwe.