Leaderboard

The way the Ctrl+Tab shortcut works in the Delphi IDE was always very inconvenient for me. Actually the Delphi IDE is the only program I can think of that does not navigate open documents based on the order in which they were last activated but instead on the order in which the tabs are arranged in the editor. So if you are were working in DocumentPrevious and switch to DocumentNext, I am used to going back to DocumentPrevious by hitting Ctrl+Tab. But in the Delphi you will navigate to whatever document is on the right side of DocumentNext. This has always been very annoying for me. Anyhow I made plugin that makes Ctrl+Tab behave to what I am used to from other programs, like Visual Studio for example. Might be of use for some. https://github.com/santiagoIT/DelphiCtrlTab Precompiled binaries are available for Delphi Seattle, Rio and Sydney.

The workaround for both issues is to follow a pattern such as this: Form.SetParent(Panel); Form.HandleNeeded; Form.ScaleForPPI(Panel.CurrentPPI);

Yes. Without that I wouldn't use them.

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?

Fair enough. I've come to use them a lot. Often I have to remind myself to use a new feature after it's introduced but this one feels so natural that I'm not thinking about it all. If anything I have to remind myself not to use it too much. The ternary operator. Didn't like it when my main language was C++ and I still don't like it. For me it somehow breaks the flow when I'm reading code.

Why so sad? Because of the leak?

You are not alone: Parented controls with free notifications aren't scaled Frame with Assigned PopupMenu is wrong Displayed on high DPI A scaled form gets resized to design time ClientWidth/ClientHeight when embeded in a parent form

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.

Imagine if you have users with names that don't begin with one of the 26 letters used in the English language? What you should do is abandon this UI approach and let the user type.

Do not rely on RcvdCount to know if data is ready to be read. In some case, winsock returns 0 even if more data is available. Just call Receive and use the return value. Call Receive again until Receive returns < 0. This is not an ICS issue but a known Winsock behaviour, that's why you experience the issue with both ICS and your old socket component.

@Mike Torrettinni Am happy the plugin is of use to you. Great suggestion 🙂 Modified files are now marked with an asterisk. I think that works well enough.

It's not only about deleting components, it basically affects any change, like reparenting, renaming and even resizing. The best part is that you will only find out by either viewing the parent form/frame in the IDE, or at runtime. The core reason is that inherited forms/frames/data modules often (not always) have extreme redundancy. Look at their DFM files. They repeat their parents content. This is especially funny when you have a huge ImageList that gets copied again and again into dozens of subclasses. The only solution I could ever find is to always pay attention to your DFM files. At every commit in your source control system, do check out your DFM files! Undo changes that were added automatically although you didn't change anything. When I work in Delphi with things that involve the user interface, I spend roughly 30 % of my time reverting redundant changes in DFM files.

I say Fastreport. I think he can all what you want...