aehimself

Hello, I would like to have a TMemo in my application, where the user could manually toggle the WordWrap property. When changing this property though runtime, the change has no effect on the display whatsoever. I did my homework, and I see only one reference to FWordWrap in the TCustomMemo implementation, which is this block: procedure TCustomMemo.CreateParams(var Params: TCreateParams); const ScrollBar: array[System.UITypes.TScrollStyle] of DWORD = (0, WS_HSCROLL, WS_VSCROLL, WS_HSCROLL or WS_VSCROLL); WordWraps: array[Boolean] of DWORD = (0, ES_AUTOHSCROLL); begin inherited CreateParams(Params); with Params do Style := Style and not WordWraps[FWordWrap] or ES_MULTILINE or ScrollBar[FScrollBars]; end; The setter looks like this: procedure TCustomMemo.SetWordWrap(Value: Boolean); begin if Value <> FWordWrap then begin FWordWrap := Value; RecreateWnd; end; end; Placing a breakpoint in CreateParams confirms that RecreateWnd triggers the call of CreateParams, where FWordWrap already has the most recently set value, however it does not change the behavior. Google only lead me to one question on the FPC forums, but with no viable solution. Is there a way to make this work without using a 3rd party component?

I can see the logic in there but this is why scrollbars can be disabled. I expected that the horizontal scrollbar will become disabled and word wrapping starts to happen. Well, anyway. At least it works now.

No, RichEdit works just fine. And I accidentally found the solution... it's the scrollbar. Begin TextEditor.WordWrap := Not TextEditor.WordWrap; End; doesn't do anything. Begin TextEditor.WordWrap := Not TextEditor.WordWrap; If TextEditor.WordWrap Then TextEditor.ScrollBars := ssVertical Else TextEditor.ScrollBars := ssBoth; End; works like a charm.

@Remy Lebeau No, not yet, was a good idea. Unfortunately though it makes no difference: Var s: String; begin s := Memo1.Lines.Text; Memo1.Clear; Memo1.WordWrap := Not Memo1.WordWrap; Memo1.Lines.Text := s; end

I know. When I used the term "packet" I referred to the packet the Client sent and which has to be re-assembled on server side from the stream of bytes 🙂

I'm not exactly sure if I got what you meant. The fixed size buffer is only used in the dataavailable evnt to read x bytes out from the socket. Then, there is an inner cycle to process the data in this inner buffer. If a packet ended within it, it copies the missing bytes to a different (variable size; set by the size indicator) buffer, sends that for processing, reads the size indicator and resets it. Until there is nothing else to be processed. Since I made the latest modifications, this logic seems to function properly - however there was no fragmented packet yet (when the beginning and the end arrive in two different handlers, possibly delayed)

Would you be so kind to explain more...? We do struggle with random IDE crashes / slowdowns / paint glitches since day 0. So far I thought it's because of our custom components....

Yes, yes, yes, that is the name. I use it a lot, and I keep forgetting it's name. I should seriously consider inking it on my wrist. Not only the question mark, though. That wouldn't help much. That's the beauty of it, no? For me, inline variable declarations are making the code harder to read, for you it's ternary operators. I have a colleague who always writes if (expression == false) instead of if (!expression) because he admitted he misses the exclamation mark about 80% of the times. All in all - even if you don't use many of them - it's good to have a bigger toolset to choose from when you are coding. We just have our preferences. Edit: never thought about it, but do inline variables work like in C#? For example if (condition) { String myStr = ""; } myStr = "Hello world"; will not compile, as inline variables are local to the current block. Does it behave the same way in Delphi?

Huge +1 to @Der schöne Günther. At work we have 2-5 levels of inherited frames and meet this kind of issue every single day. Reviewing DFMs became a tradition, especially since Delphi tends to move components around with +-1 pixels upon saving - even if you didn't touch them. Edit: It was like this back in 10.0 Seattle as far as I can remember. It's not only affecting 10.4(.1).

Leaks are easy to be fixed, no. I just personally dislike inline variable declarations. If the Delphi language is moving closer to C#, they could have implemented something useful like Linq or the "?" operator when assigning values to variables (String myVar = inCondition ? "" : otherClass.SringProperty; forgot the name, sorry) in my opinion; that's all.

Yep, that's exactly what I do now. I have an outer cycle: Repeat // Receive the fixed size buffer (set in constructor) read := Self.Receive(@_rcvbuf[0], Length(_rcvbuf)); If read <= 0 Then Break; [...] Until False; Within this cycle, I have an internal cycle which is assembling the packets to be decrypted from _rcvbuf; based on the size indicator. If the packet did not fit in _rcvbuf, the next outer cycle will read out the next fragment. This method seems to be working, packets are flowing in and being decrypted correctly. I just have to wait a couple of days to see if the lock-up happens again or not.

Indeed I did! My brain simply didn't process that the event is not placing the data in the beginning of InBuf... guess I'd finally need some sleep? I went on with the more difficult version however. I'm reading a fixed size (let's say 200 bytes). If the packet buffer is empty, I read the size and set the packet buffer to that size. If not, I'm appending as many bytes as needed / possible from this 200. If all was processed, I read the next 200 until there's none left. If it works (and I do have my hopes high) I'll move some processing parts to submethods to make the main one easier to read.

Indeed. This reminds me to https://qz.com/679782/programmers-imagine-the-most-ridiculous-ways-to-input-a-phone-number/

Hello, I'm in the process to migrate an old code from TClientSocket to an ICS TWSocket. All seems to work fine, except the OnConnect & OnDisconnect handlers. Create a new VLC project, with a TWSocket and a memo on it and use the following code: Function SocketStateToString(Const inSocketState: TSocketState): String; Begin Case inSocketState Of wsInvalidState: Result := 'invalid'; wsOpened: Result := 'opened'; wsBound: Result := 'bound'; wsConnecting: Result := 'connecting'; wsSocksConnected: Result := 'socks connected'; wsConnected: Result := 'connected'; wsAccepting: Result := 'accepting'; wsListening: Result := 'listening'; wsClosed: Result := 'closed'; wsDnsLookup: Result := 'DNS lookup'; Else Result := 'unknown'; End; End; procedure TForm3.FormCreate(Sender: TObject); begin WSocket1.Connect; end; procedure TForm3.WSocket1ChangeState(Sender: TObject; OldState, NewState: TSocketState); begin Memo1.Lines.Add('State change from ' + SocketStateToString(OldState) + ' to ' + SocketStateToString(NewState)); end; procedure TForm3.WSocket1SessionClosed(Sender: TObject; ErrCode: Word); begin Memo1.Lines.Add('Session closed'); end; procedure TForm3.WSocket1SessionConnected(Sender: TObject; ErrCode: Word); begin Memo1.Lines.Add('Session connected.'); end; Set the WSocket's Addr to 127.0.0.1 and the port to 1024. Make sure no application listens. When I run the above code, I get the following result: State change from closed to opened State change from opened to connecting State change from connecting to connected Session connected. State change from connected to closed Session closed The state goes to connected for a brief moment, also session is connected... to nothing (?) before both goes back to closed. What is the normal place to put my code in, which is granted to run ONLY if the socket was really connected and disconnected? Edit: I'm using ICS vV8.64 on Delphi 10.4.1

The code you sent will not work, as it is always reading out the packet size. If the following scenario occurs: it will consider the beginning of the second event as a new packet size.

I will be honest, I did not understand how it can stop receiving, up until this point. It all makes sense now. I'm in the progress of re-writing it this way, we'll see if that will bring success. Edit: the lockup indeed happens when there is a significantly larger amount of data incoming (6-7 * 150 bytes instead of 80) so that also confirms this theory. I finished converting the read-out logic and deployed it on the test server. We will see in a couple of days if it worked 🙂

Unfortunately, it seems to me that the error was not with the component after all. My current implementation of traffic handling seems to be correct, but I have exactly the same issue as with TClientSocket / TServerSocket. As it doesn't seem to be ICS-related, I opened a new topic for it:

😢

I didn't know that there is an actual expression for this. Sounds familiar though, I guess I did it lots of times as well.

And I seriously missed that, I just don't know how. Using the SessionConnected handler WITH a small check to the error code works - as designed I suppose 🙂 Let's hope that changing to a little bit more up-to-date component will solve the connectivity issues I had! This was the part I was missing; coming from an old, outdated component I expected the stateflow to be different if a connection attempt fails or succeeds. I was just unsure if I did something wrong in other parts of my code, or not. I'm an ICS newbie. I'll learn 🙂

That's the trick. There is NOTHING listening on that port - therefore no data to be received. The result is the same if I set the addr to '99.88.77.66' or other nonsense - I expect nothing to be there. This is why I said:

Because it's the mainstream. I bet my shoes on that you can track it back to Apple.

Manually handling it in OnMouseMove works perfectly.

Possible, however there are no requests like that for the time being. And this is why I hate to implement something new. The next hour when I published the resizable multi-line editor an other request came in, that "it would be nice" if the editor would resize with the form itself, instead of showing a scrollbar 😄

I'll only post a picture.