Remy Lebeau

I find it interesting that you clearly knew how to access the element values in the 1st range-for loop, but didn't know how to do the exact same thing in the 2nd range-for loop.

None of the operations you are doing perform any bounds checking. They don't even know the size of your buffers. Your code exhibits undefined behavior if your input overflows the buffers. To avoid this, use std::cin.get() or std::cin.getline(), which allow you to specify the buffer sizes. Or better, just use std::string instead of char[].

Are you able to create a fresh project from scratch and compile+link it before adding anything to it? When you say "copying everything from my 11.3 project", did you actually add the files to the new project, or just drop them in the project folder?

TThreadedQueue has a public Grow() method to increase the queue size. What I find odd, though, is that Grow() is not called automatically by PushItem(). Instead, if the queue is full then PushItem() simply waits (up to the specified PushTimeout at creation) for outside code to call either PopItem() or Grow() to make room for the new item. So, in that regard, I suppose it acts as a fixed-capacity buffer. But the capacity can be changed dynamically nonetheless. Because it really does. Then the documentation is wrong. The implementation code tells a different story. 🤷‍♂️ I don't know. There is - the public Grow() method.

I very much doubt that. You are probably just using it incorrectly. Can you provide some code?

Because teTextLabel is a TThemedElement enum value but GetTextExtent() wants a TThemedElementDetails record instead.

C++ Precompiled Header File (*.pch) Precompiled Headers Overview

What are the EXACT error messages? What EXACTLY did you try? What are your EXACT property settings? Umm, you are comparing a higher-level APPLICATION to a lower-level LIBRARY. Of course, a LIBRARY is going to be more flexible and thus require more configuration for meet your particular situation. Seems simple enough. Please show the EXACT code you are trying to use to accomplish that. Then you don't have TIdFTP setup correctly to match your server's requirements. Those are not the only settings involved. What ELSE do you have configured EXACTLY? Well, then you should have no trouble grabbing logs from CoreFTP and TIdFTP and compare them for differences. At what stage EXACTLY in the communication is the failure actually occurring? There are several different possibilities, which is why more DETAIL is needed. Probably, but without any DETAIL about your setup or your server's requirements, there is simply no way for anyone here to know for sure what is actually wrong/missing. Provided the server is actually reachable and responsive, most often a timeout error on a connect is due to a mismatch between the Port and UseTLS properties, causing Indy to wait for a server greeting that is never sent because the server is waiting for a TLS handshake from the client first. Again, what is the EXACT error message? Is it an FTP-level error or a TLS-level error? You can't set the UseTLS property to Explicit (or Implicit) without having an SSLIOHandler assigned first.

XPath parses only XML. You can't use XPath to parse plain HTML. It can parse XHTML, which is HTML using XML syntax.

Yes, you can. And it works perfectly fine on the Delphi side. It is only on the C++ side that you may run into trouble, and I already explained how to work around that. The issue is not about the dots themselves, but with the names you put in between the dots. It is your responsibility to make sure those names don't conflict. And instruct the C++ compiler how to handle them correctly if needed.

Then you should have posted the code as a reply to that earlier discussion. Instead, you posted it as a new discussion with no context. At least add a link to the original discussion.

There are three options for influencing the height of TListView items: 1. Assign an ImageList of desired size. 2. Assign a Font of sufficient size. 3. Owner-draw the TListView and handle the WM_MEASUREITEM notification in the parent window (or subclass the TListView to handle CN_MEASUREITEM). No, there is not.

By default, Pascal-generated HPP headers bring their C++ namespaces into the namespace that is #include'ing the HPP file (which is usually the global scope). So, in this case, there are two Fmx namespaces in the same scope, and the compiler ends up picking your namespace instead of FireMonkey's, which is why it can't find the Fmx::Controls namespace. If you look at your HPP files, you will notice that there are 'using namespace' statements at the bottom which are wrapped in preprocessor blocks, eg: #if !defined(DELPHIHEADER_NO_IMPLICIT_NAMESPACE_USE) && !defined(NO_USING_NAMESPACE_EHLIB_FMX_TYPE) using namespace EhLib.Fmx.Type; #endif #if !defined(DELPHIHEADER_NO_IMPLICIT_NAMESPACE_USE) && !defined(NO_USING_NAMESPACE_EHLIB_FMX) using namespace EhLib.Fmx; #endif #if !defined(DELPHIHEADER_NO_IMPLICIT_NAMESPACE_USE) && !defined(NO_USING_NAMESPACE_EHLIB) using namespace EhLib; #endif To avoid this ambiguity, you can specify either DELPHIHEADER_NO_IMPLICIT_NAMESPACE_USE or the desired NO_USING_NAMESPACE_... conditional(s) in the "Conditional defines" section of your C++ project's settings. Or, at least, simply #define them above the relevant #include statement(s) in your C++ code. Alternatively, another workaround would be to add {$HPPEMIT NOUSINGNAMESPACE} to your Pascal units to avoid any 'using namespace' statements in their generated HPP files.

In fact, this is likely the root culprit of your other issue, as you probably have multiple Fmx namespaces in the same scope that are interfering with each other. In addition to what I mentioned above, another workaround would be to add {$HPPEMIT NOUSINGNAMESPACE} to your Pascal units to avoid any 'using namespace' statements in their generated HPP files.

Yes, it does. You just have to be a little strategic with it. That is correct. By default, Pascal-generated HPP headers bring their C++ namespaces into the namespace that is #include'ing the HPP file (which is usually the global scope). And since both Vcl namespaces are in the same scope, the compiler doesn't know which one to use, hence the ambiguity error. If you look closer at the HPP files, you will notice that those 'using namespace' statements are wrapped in preprocessor blocks, eg: #if !defined(DELPHIHEADER_NO_IMPLICIT_NAMESPACE_USE) && !defined(NO_USING_NAMESPACE_VCL_BUTTONS) using namespace Vcl::Buttons; #endif #if !defined(DELPHIHEADER_NO_IMPLICIT_NAMESPACE_USE) && !defined(NO_USING_NAMESPACE_VCL) using namespace Vcl; #endif To avoid the ambiguity, you can specify either DELPHIHEADER_NO_IMPLICIT_NAMESPACE_USE or the desired NO_USING_NAMESPACE_... conditional(s) in the "Conditional defines" section of your C++ project's settings. Or, at least, simply #define them above the relevant #include statement(s) in your C++ code.

Correct. If you want to use your Frames, then I would suggest using a plain TPanel, put your visible Frames on it, and then use a separate TScrollBar to "scroll" through your data, updating the Frames accordingly. If you want to use a virtual TListView, you will have to custom-draw anything beyond simple text. You can try using the TListItem.SubItemImages property or TListView.OnGetSubItemImage event, but I'm not sure if those work in virtual mode or not. I have never used them. I always custom-draw my own images. You can't add an actual button control to a TListView item. You would have to custom-draw an image of a button instead, and then handle the TListView.OnMouse(Down|Up) events to know where the user is clicking within the TListView. You can use the TListView.GetItemAt() and TListView.GetHitTestInfoAt() methods to know which item is underneath the mouse, and in some cases even which portion of the item. However, in the case of your eye button, that is not granular enough, so I would suggest sending an LVM_SUBITEMHITTEST message to the TListView window, which will tell you the item and column indexes that are at a given coordinate. And if needed, there is also the LVM_GETSUBITEMRECT message which gets the display coordinates of a given column within an item.

The Win32 constants are being declared in the SDK using #define statements, which are parsed during the preprocess stage, and are just straight text replacements. As such, they don't respect C++ namespaces at the compile stage, as the code has already been modified by the preprocessor before the compiler sees it. Thus, the compiler will not see this code, as you expect: namespace Ehlibfmx { namespace Toolcontrols { static _DELPHI_CONST System::Int8 SB_HORZ = System::Int8(0x0); } } But will see this code instead: namespace Ehlibfmx { namespace Toolcontrols { static _DELPHI_CONST System::Int8 0 = System::Int8(0x0); } } Which is a syntax error in the C++ language.

Those constants are already defined in the Win32 SDK headers (specifically, in winuser.h) using #define macros: /* * Scroll Bar Constants */ #define SB_HORZ 0 #define SB_VERT 1 #define SB_CTL 2 #define SB_BOTH 3 That will interfere with any C++ code that tries to use your constants for ANY reason (including the declarations!). For example: static _DELPHI_CONST System::Int8 SB_HORZ = System::Int8(0x0); This will be misinterpreted by the C++ compiler as the following instead, hence the error you are getting: static _DELPHI_CONST System::Int8 0 = System::Int8(0x0); To avoid this, don't redeclare Win32 constants in C++. Declare your constants in your Pascal unit as {$EXTERNALSYM} (or {$NODEFINE}) so they are omitted in your generated HPP file: const { Scroll Bar Constants } {$EXTERNALSYM SB_HORZ} SB_HORZ = 0; {$EXTERNALSYM SB_VERT} SB_VERT = 1; {$EXTERNALSYM SB_CTL} SB_CTL = 2; {$EXTERNALSYM SB_BOTH} SB_BOTH = 3; Alternatively, change your Pascal unit to use the constants that are already declared in the Winapi.Windows unit, which are EXTERNALSYM'ed (just be sure to {$IFDEF} that unit since you appear to be coding for FMX).

And, the point of this post is... what, exactly? I don't see a question or problem stated. However, why were you ever mixing C's <conio.h> with C++'s <iostream> in the first place? Get rid of <conio.h>, you don't need it. Use std::cin.get() instead of getch().

Set TListView.OwnerData=true, set TListView.Items.Count to the number of items you want to display, and use the TListView.OnData event to provide details for each item on demand. The scrollbar will be handled for you. Because those are TListBox styles, not TListView styles. In this situation, set TListView.ViewStyle=vsReport, and add some columns to the TListView.Columns. Then, in the TListView.OnData event, you can provide data for the 1st column using TListItem.Caption, and data for the subsequent columns using TListItem.SubItems. Use the TListView.OnData... events for that purpose. Yes. Probably because you didn't populate the TListView with data yet (see above). Yes. You should not be putting any child controls on to the TListView at all. It is not designed for that. Let it handle the items for you. You just worry about supplying the items with data. And using the TListView.On...Draw... events if you want to custom-draw the items. No. It is just a wrapper for the native behavior provided by Microsoft, see: How to Use Virtual List-View Controls

That is an extremely old header file for DOS development. If you are using C++ iostreams for console I/O (as you should be, ie std::cin and std::cout) then you don't need that header. Or std::cin.get(). But yes, to keep the window open, you have to wait for user input. Otherwise, open the console window first before then running the program in it. The window closes automatically only if the program launched the window in the first place. When you run a console program directly, it creates a new console window for itself. Not that I'm aware of. But without seeing the actual code, it is difficult to explain what you are experiencing.

Does EhLib.Fmx.Types.pas have the FMX.Controls unit in its 'interface' uses clause? Does the generated EhLib.Fmx.Type.hpp file have an #include <FMX.Controls.hpp> statement?

Nothing. ReadOnly has no meaning for a folder and is ignored. This is documented behavior: https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-setfileattributesw Making a folder read-only is an illusion. When you do it in Explorer, it iterates the folder's files and updates them accordingly. You can't change the attribute on the folder itself. Doing so is reserved by Windows for its private use on system folders. You cannot view or change the Read-only or the System attributes of folders in Windows Server 2003, in Windows XP, in Windows Vista or in Windows 7

Show off 😉 Thanks, I have added it to the bug report.

That is not what I would call a MINIMAL example, but at least it compiles this time. There is still a lot of IRRELEVANT code that has nothing at all to do with demonstrating the issue at hand. But so be it. Your TBaseConnectionParams and TSqliteParams classes are duplicating similar code because THEY ARE RETURNING DIFFERENT THINGS, so how to do you expect one to just inherit the behavior of the other? They can't. If you really want to make use of class inheritance then you need to simplify the design of the common elements so they are coherent and overridable across descendants. You are not even override'ing the base methods, you are reintroduce'ing them. That is not how inheritance works.