Brainstorm

@Asperamanca, I would like to inform you that Aspose.Words for C++ is an advanced Word Document Processing API to perform a wide range of processing tasks. API provides document formatting, manipulation, mail merge, watermarking and much more capabilities directly within your own C++ applications without requiring Microsoft Word. API supports most of the Microsoft Word formats for processing. You can even integrate this native C++ API within your Qt application. I am sharing here an example cmake project which uses Qt and Aspose.Words for C++. Then please do the following steps: Download and install cmake Download and unpack Aspose.Words for C++ library Copy Aspose.Words.Cpp and CodePorting.Native.Cs2Cpp_vc14_20.3 folders next to CMakeLists.txt file Run the following command from command line: cd qthw cmake -G "Visual Studio 15 2017" -Thost=x64 -Ax64 -S . -B build -D"Qt5_DIR=<path-to-qt5>" path-to-qt5 should be something like -x:\QT\5.14.2\msvc2017_64\lib\cmake\Qt5 - path to folder with Qt5Config.cmake file It should create Visual Studio 2017 Solution with a proper setup for Qt and Aspose.Words for C++.

OK, thanks for the input, guys. I'll continue with my current method.

Thanks for the input, guys. Jon makes a good point about the need to convey this "hidden" feature to the user. That said, I might go ahead and try implementing this, simply because I can foresee a lot of good uses for the QKeyEvents. I can always go back and implement something that Jon could live with. Thanks again... EDIT: QKeyEvents aren't a great solution. It turns out that, on Windows and Linux (but not Mac), holding down keys prevents a button push from signalling. You have to press and release the keys, then push the button. Much clunkier than I'd hoped for.

Does it update in real time? If it does then what events happen on one should be sent to the other. Like @eyllanesc said, those would be the "instructions" of what to draw.

@mzimmers If i iterate over the interfaces like in your script, then it works with no problem :) Running on windows :) When using only the QHostAddress::Broadcast I get the wrong broadcast addr. I too think it is strange, but this is no issue for me, as it's always simple to determine the right address by code or manually :) just strange as you say :) Anways, off to new issues :D

Thanks for the suggestions. I'm sure I'll have more questions about implementation, but as the original issue has been answered, I'm marking this as solved.

@JonB Thanks a lot for your insight!

@EHSUN7B If you want to publish source code also then there is nothing special to consider. If you do not want to deliver source code then use LGPL license for Qt and use Qt shared libraries. When using static Qt libraries you have to be prepared to give the users the object files so they can relink the app against their own Qt libs. Note: I'm not a lawyer.

@Konstantin-Tokarev I think you're saying I'm wrong and then restating exactly what I wrote in the first place? The default allocator reverts to the default heap manager and I'm well aware that it can be overriden, as I mentioned that as a potential strategy. so yes, it is implicit in the default STL. Normally I stay well away from boost. Historically the lack of real boost documentation and frequently changing interfaces have left me severely jaded where boost is concerned. If/when something from boost finds its way into the standard then I'm more likely to give it a whirl, but I may take a look at their pool allocators. Thanks!

@aha_1980 Thank you for your kind reply and.... you are right, is not enough replace the name of the linked dll.

Does it satisfy the requirements for BSD and MIT? I mean it is easy to find. Who does not know "Help > About" ? at first you will see a list of all third party libraries. You can look how other companies (like Apple, Google, or, surprise, Qt itself) are handling 3rd-party BSD/MIT licensed code. It may be buried deep down in app or documentation and it's still ok because persistent user can find it. But If I changed it I would have released them as open source under the same License. BSD and MIT allow any modifications in code without requirement to publish them, as long as you comply with their terms. Read licenses, they are very concise..

@AndyS @JKSH @Konstantin-Tokarev @bterrier Thanks for the answers. I read into the details of the GPL and LGPL licenses and it looks like (for my Qt library use) i don't need to purchase a license.

what you are asking for is POSIX TZ format. It can be pulled or generated from the POSIX tzfile(5) database. A quick search of the database on my machine shows that all of the timesonze files I searched contained a newline terminated TZ string fallback for dates after the prior exception rules. You most likely would have to parse the tzfiles according to the zone selected and use the fallback string if it exists, or build the correct string from the data if it doesn't exist. This of course assumes that you are on a unix/linux machine.

FWIW, if you make your project open source under GPL license, and not planning to sell devices which runit as a part of firmware, you can also ignore all license stuff and be safe. But if you are planning to produce such devices, it's better to consult a lawyer, though it's still possible to do with open source Qt if users can reflash device or have read-write access to its file system and can build their own Qt for them.

Hi @ludek-vodicka, But who you think to contact? These AV companies? Yeah, these are the only ones that can update their whitelists. Regards

@Vova-Shevchyk this is a bit old, but I want to check how's the work on this website going?

Hi, If you'd like to interact with Qt developers, you should rather post your Qt6 related questions on the interest mailing list. You'll find there Qt developers/maintainers. This forum is more user oriented.

In that case comment all the code that makes the test crash and te-add stuff gradually until the test starts to crash again. It should give you clues about what is going on.

And further to what @SGaist has just said about licensing required for static, I would have thought you would probably run the same risk with your "all Qt DLLs into one DLL". The LGPL requires users should be able to just use a new set of Qt DLLs with your software, recompile Qt for themselves etc., and that might not hold (in a straightforward fashion) if you start replacing the standard, freely available Qt DLLs with some concoction you create yourself.