aehimself

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.

Just a small update, I managed to implement the resizing logic and it was really, really easy. Most of my time went away by drawing the transparent, themed, system default resize gripper... ...which almost can not be seen on dark styles, so totally with it! 👍 Frames above and below are adjusting properly, not changing places or jumping around. Overflow is handled correctly by the alClient scrollbox, if the contents grow too large for the window. The only thing is that I did not use splitters, I wrote the resizing logic myself (which is awfully long, like 10 lines of code?) Procedure TMultiLineParamFrame.ResizeHandleImageMouseDown(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Integer); Begin _resizing := True; SetCapture(Self.Handle); End; Procedure TMultiLineParamFrame.ResizeHandleImageMouseMove(Sender: TObject; Shift: TShiftState; X, Y: Integer); var relative: TPoint; begin If Not _resizing Then Exit; relative := ScreenToClient(Mouse.CursorPos); If relative.Y > 47 Then Height := relative.Y; // Burned in magic number, because we all love them! End; Procedure TMultiLineParamFrame.ResizeHandleImageMouseUp(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Integer); Begin ReleaseCapture; _resizing := False; End; Drawing the gripping handle: Constructor TMultiLineParamFrame.Create(AOwner: TComponent); Var bmp: TBitmap; Begin inherited; _resizing := False; bmp := TBitmap.Create; Try bmp.Height := 16; bmp.Width := 16; bmp.TransparentColor := clYellow; bmp.Canvas.Brush.Color := bmp.TransparentColor; bmp.Canvas.FillRect(Rect(0, 0, bmp.Width, bmp.Height)); StyleServices.DrawElement(bmp.Canvas.Handle, StyleServices.GetElementDetails(tsGripper), Rect(0, 0, bmp.Width, bmp.Height)); ResizeHandleImage.Picture.Assign(bmp); Finally FreeAndNil(bmp); End; End;

I just found this awesome thing of @RRUZ, called TSMBIOS. Unfortunately though it seems to be abandoned now, and the only result I get on an Ubuntu 18.04 server is a nullpointer exception; even if I execute it via sudo (or su). Does anyone know about an updated fork of this component or something similar; which can gather hardware information on Windows and Linux?

Nice job. I think soon I'll need something like this in one of my applications - at least I'll know where to look 🙂

Especially if our own code is doing things like this. God, how many hours we already spent debugging something which only triggers when several, rare conditions are met 🙂

Really nice idea! As the shapes are not even that complicated, it could be custom-drawn on a TWinControl-descendant and call it a component. I like it.

With all respect, I don't think Git structure is the root cause here; refactoring the 850 EXEs to one single application plus modules (not necessarily .DLLs) would worth more on the long run in my opinion. Most of us, Delphi developers were hired to maintain old, large (and often poorly written) legacy applications; I know how likely the management approves 1-2 devs to "break free" and start re-designing everything. But, with properly structured and divided code, you'll quickly see that there will be no need of mapping one git repository to a number of drives. Thus, achieving your current goal to reduce merge conflicts.