TTMSFNCChat triggers OnBeforeSendMessage and OnAfterSendMessage events, even when messages are programmatically added via .AddMessage. Could do it adding directly to the ChatMessages collection, but AddMessage has the advantage to automatically format the ChatItem according to DefaultLeftItem / DefaultRightItem settings.
It was mentioned before:
The source code does not check if the send button was really used, and InternalAddMessage procedure always calls DoBeforeSendButtonMessage and DoAfterSendButtonMessage.
My turnaround is saving => setting nil => restoringOnAfterSendMessage and OnBeforeSendMessage events on every AddMessage I do. It would be great if worked as expected when there's no button click. Maybe the send button click/tap event should run the beforesend / aftersend routines before and after calling the AddMessage routine.
Your Demo (Demos\VCL\Chat\) behaves this way.
Run Server, then run 2 clients.
Send a message from a client, when client2 receives it and calls .AddMessage it'll trigger the OnAfterSendMessage, and send it to the server, then client 2 will receive and resend , and so on.
There's another problem to which I couldn't find a turnaroud yet: I can't see the cursor while typing a message. It happens using the Demo, and also in my own VCL application.
The idea behind OnBeforeSendMessage and OnAfterSendMessage is to be able to capture all messages (text, image, files, doesn't matter if programmatic or via the button). The ChatMessages collection of course is an exception, because it is being directly manipulated and we cannot prevent adding messages that way via an event.
From what I understand, you need an event that is only triggered when messages are sent via the send button with an option to reject them, is that correct?
In that case we can extend the component with events such as OnBeforeSendButtonMessage and OnSendAfterButtonMessage that would behave the same as OnBeforeSendMessage and OnAfterSendMessage, but they would only trigger for the send button interaction. This would also avoid breaking changes for people who depend on the current behavior of OnBeforeSendMessage/OnAfterSendMessage.
We could reproduce this, but we were also able to reproduce it with a simple TEdit and TMemo (which is being used internally by TTMSFNCChat). It is probably related to a Windows setting, e.g. hide while typing.
Please notice that when you're adding a message programmatically you're not necessarily sending it.
Your demo proved the point.
In my specific case, loading a conversation history and using AddMessage raised this issue. It's adding a message, and a supposedly sending event is being triggered.
The same happens when the demo receive a message from the server and adds it to the FNCChat via AddMessage. I'm sure there's no need to keep this kind of backward compatibility
How can it be a windows setting I hadn't even know that existed when everything but the FNCChat typing box is running ok ?
So you've set windows to hide cursor, or it happened without intervention?
While that is true, the convenience methods like AddMessage were added with sending in mind. Some people use their own text area + button and only keep the message area on display. In their case it would be a breaking change.
To avoid that, we can:
Add new events that trigger for the button only
Add a default parameter to the methods to control the event triggering
So you cannot reproduce this with a simple TEdit or TMemo dropped onto the form? TTMSFNCChat is using TMemo for the text area, it should behave the same.
This is without modifying any settings. Hide while typing is enabled by default, but disabling it didn't make a difference here after testing it. Mind you, on our system this keeps happening in all Windows Edit Control, even with things outside of Delphi. It could be a Windows bug for all we know, we simply cannot reproduce this with TTMSFNCChat only.
I mean when I click the FNCChat typing box, whatever it is, memo or edit, the text cursor is not shown. If I use backspace or move left with an arrow, the cursor is not visible. Other edit controls in my app forms are ok, showing the cursor when you need to know where it is
You mean this caret?
I thought you were talking about the mouse cursor. In that case, as you can see on the image we cannot reproduce that with our default setup. A few follow up questions to attempt to replicate it here:
Which IDE and Windows version are you on?
Is there something specific to your form/application? Meaning, do you still experience this when dropping TTMSFNCChat in a new test application to a blank form?
Did you change any property settings (to see what we also need to change here)?
Using the demo on 2 windows 11 devices, one w/ Delphi 12.2 , the other w/ Delphi 11. In both, there's no cursor. Didn't test my app on the Delphi 12 device, but it was a new object used in a different application (not a blank form). As I said before, every other edit controls in the same form are ok.
Please verify.
It has something to do with focus.
When they're are no other non-fnc focusable edit controls in the same form, there's no problem.
It works well in a blank form.
Works well in a form that has an FNCEdit.
Drop a native TEdit, and then the FNCChat memo cursor is gone.
Sometimes you focus outside of the form and come back directly to the chat memo and the cursor appears, but move to the TEdit and back to the chat, and it's gone again.
Could you please also check it's scrolling, auto scrolling to bottom, and repainting routines when user is not at the bottom and a new message "arrives" ? It's a little messy.
You can see it running the Client demo. Send many messages until it needs scrolling. Go some messages up, and then keep on sending more messages. It's unpredictable.
Scroll up/down near the bottom. Not so clear behaviour.
Before testing, make this form border bsSizeable, so you'll be able to test distinct scrolling scenarios.
(As for the last version, opening a second demo Client and sending messages would make it loop forever.
Will the demo, or the AddMessage issue be fixed?)
