Hi, congratulation, I compiled all the 50 examples with VS2015 in Windows 7 Pro 64x using debug Win32 and static linked cpp run time: (I returned some configuration to the project)

Commit: e46c5e46d766be6e10ed10bc00aed23012dbf8da [e46c5e4] Parents: 09b314b94c Author: Jinhao [email protected] Date: Donnerstag, 22. Oktober 2015 18:56:10 Labels: HEAD, nana_jinhao/develop, cnjinhao/develop, develop fix leak of memory for class animation

and with 0 errors and 0 warnings.

Now I will run each and test and will write here the results.

• [ ] Visual-Studio-2019-cmake-open-folder-style-project vs2019 Windows 7 cmake: 3.16.0 develop分支

错误：

CMake Error at build/cmake/select_filesystem.cmake:57 (check_include_file_cxx):
  Unknown CMake command "check_include_file_cxx".
Call Stack (most recent call first):
  CMakeLists.txt:135 (include)

57行加上： include (CheckIncludeFileCXX)

解决之后：

Looking for C++ include filesystem
Looking for C++ include filesystem - found
Looking for C++ include experimental/filesystem
Looking for C++ include experimental/filesystem - found
C++ Filesystem header:      <filesystem>
Performing Test CXX17_BUILTIN
Performing Test CXX17_BUILTIN - Failed
Performing Test CXX17_FLAG
Performing Test CXX17_FLAG - Failed
CMake Warning at build/cmake/select_filesystem.cmake:115 (message):
  nana requires C++17??, but your compiler does not support it.
Call Stack (most recent call first):
  CMakeLists.txt:135 (include)

__cplusplus < 201703L 在msvc下似乎要加： /Zc:__cplusplus /std:c++latest

改成： set (CMAKE_REQUIRED_FLAGS "/Zc:__cplusplus /std:c++latest ${CMAKE_CXX_FLAGS}") 可以正常编译。

参考链接： https://devblogs.microsoft.com/cppblog/msvc-now-correctly-reports-__cplusplus/

Given that the main thread is pumping events, and a worker thread is creating a nana::listbox, my code is deadlocking. No thread has acquired any mutex that I create.

Here are the call stacks: Worker Thread [External Code]

NetworkIntegrityChecker.exe!nana::detail::window_manager::revertible_mutex::lock() Line 308 C++ NetworkIntegrityChecker.exe!nana::internal_scope_guard::internal_scope_guard() Line 33 C++ NetworkIntegrityChecker.exe!nana::API::dev::set_scheme(nana::detail::window_handle_impl * wd, nana::widget_geometrics * wdg_geom) Line 201 C++ NetworkIntegrityChecker.exe!nana::widget_objectnana::category::widget_tag,nana::drawerbase::listbox::trigger,nana::drawerbase::listbox::listbox_events,nana::drawerbase::listbox::scheme::create(nana::detail::window_handle_impl * parent_wd, const nana::rectangle & r, bool visible) Line 206 C++ NetworkIntegrityChecker.exe!nana::listbox::listbox(nana::detail::window_handle_impl * wd, bool visible) Line 5279 C++ [External Code] NetworkIntegrityChecker.exe!getList(nana::form & form, nana::place & layout, const int panid) Line 140 C++ NetworkIntegrityChecker.exe!WinMain::__l2::(std::unique_ptr<Packet const ,std::default_delete > packet) Line 316 C++ [External Code] NetworkIntegrityChecker.exe!Sniffer::Impl::work() Line 195 C++ NetworkIntegrityChecker.exe!Sniffer::Impl::{ctor}::__l2::() Line 154 C++ [External Code] NetworkIntegrityChecker.exe!invoke_thread_procedure(unsigned int(*)(void ) procedure, void * const context) Line 92 C++ NetworkIntegrityChecker.exe!thread_start<unsigned int (__cdecl)(void * __ptr64)>(void * const parameter) Line 115 C++ [External Code]

Main Thread [External Code]

NetworkIntegrityChecker.exe!nana::detail::bedrock::pump_event(nana::detail::window_handle_impl * modal_window, bool is_modal) Line 421 C++ NetworkIntegrityChecker.exe!nana::pump() Line 50 C++ NetworkIntegrityChecker.exe!nana::exec(unsigned int wait, unsigned int wait_end, std::function<void cdecl(void)> f) Line 92 C++ NetworkIntegrityChecker.exe!WinMain(HINSTANCE * hInstance, HINSTANCE__ * hPrevInstance, char * lpCmdLine, int nCmdShow) Line 420 C++ [External Code]

As discussed here.

Also adds a TravisCI build badge to the README.

How to activate:

• Before merging the PR:
  • go to https://travis-ci.org,
  • log in (if necessary),
  • click your name and avatar in the top-right corner,
  • check (click on, so it turns from grey to green) cnjinhao/nana,
  • click on the little gear icon, which will take you to the settings page,
  • check the option in the top-left corner ("Build only if .travis.yml is present").
• Merge the PR.

Now, each time a commit is pushed to a branch containing a .travis.yml file, a build will start and, if it fails, responsible individuals will be notified via e-mail. Also, if a PR is opened (and is auto-mergable), a build will start targeting the merged state.

Below is the code and steps to reproduce the issue.

#include <nana/gui.hpp>
#include <nana/gui/widgets/menubar.hpp>
#include <nana/gui/widgets/textbox.hpp>

using namespace nana;

int main()
{
    using namespace nana;
    form fm(API::make_center(400, 500));
    menubar mb;
    mb.create(fm);
    mb.push_back(L"&aaaaaa");
    mb.push_back(L"&baaaaa");
    mb.at(0).append(L"&1", [](menu::item_proxy& ip){

    });
    mb.at(0).append(L"&2", [](menu::item_proxy& ip){

    });
    mb.at(1).append(L"&1", [](menu::item_proxy& ip){

    });
    mb.at(1).append(L"&2", [](menu::item_proxy& ip){

    });

    textbox txt(fm, rectangle(10, 60, 200, 30));

    fm.show();
    exec();
}

1. Click and set focus to the textbox.
2. Click the menubar to open the menu.
3. Click a menuitem.
4. Focus of the textbox widget is lost.

The build directory after downloading the library is not empty. This itself is smelly (since CMake doesn't have a clean command many projects simply delete build dir to fully rebuild) (and for other reasons). This is already #268.

But there is a much bigger issue, actually caused by this fact: the build directory already contains makefile entry (a directory with sample makefile and a readme). CMake generates Makefile file in the root of build directory which does not conflict on UNIX systems but does on Windows because paths are case-insensitive there.

nana/
    build/
        makefile/
            makefile
            readme.md
        Makefile (name conflict on Windows)

Even more, removing the build directory itself is not an option because main CMakeLists.txt includes other files from the build directory.

Current workaround: remove nana/build/makefile directory only.

I strongly suggest to rename build directory, it is very likely to have more (undiscovered) conflicts with various build tools.

Using CMake, gcc 5.3 and Fedora 23 64-bit: After setting CMAKE_INSTALL_PREFIX to specify the installation directory, the build succeeds but the installation directory contains only libnana.a. The install directory should also contain the required include files.

MINGW64 /c/libs/nana/build/bin/netbeans8 (origin/hotfix-1.3) $ mingw32-make.exe Scanning dependencies of target nana [ 1%] Building CXX object CMakeFiles/nana.dir/source/any.cpp.obj [ 2%] Building CXX object CMakeFiles/nana.dir/source/basic_types.cpp.obj [ 3%] Building CXX object CMakeFiles/nana.dir/source/charset.cpp.obj [ 5%] Building CXX object CMakeFiles/nana.dir/source/datetime.cpp.obj [ 6%] Building CXX object CMakeFiles/nana.dir/source/deploy.cpp.obj [ 7%] Building CXX object CMakeFiles/nana.dir/source/internationalization.cpp.obj C:\libs\nana\source\internationalization.cpp:254:4: error: 'recursive_mutex' in namespace 'std' does not name a type std::recursive_mutex mutex; ^ C:\libs\nana\source\internationalization.cpp: In function 'void nana::internationalization_parts::set_eval(nana::window, nana::i18n_eval&&)': C:\libs\nana\source\internationalization.cpp:267:20: error: 'recursive_mutex' is not a member of 'std' std::lock_guardstd::recursive_mutex lock(mgr.mutex); ^ C:\libs\nana\source\internationalization.cpp:267:20: error: 'recursive_mutex' is not a member of 'std' C:\libs\nana\source\internationalization.cpp:267:40: error: template argument 1 is invalid std::lock_guardstd::recursive_mutex lock(mgr.mutex); ^ C:\libs\nana\source\internationalization.cpp:267:46: error: invalid type in declaration before '(' token std::lock_guardstd::recursive_mutex lock(mgr.mutex); ^ C:\libs\nana\source\internationalization.cpp:267:51: error: 'struct nana::internationalization_parts::eval_manager' has no member named 'mutex' std::lock_guardstd::recursive_mutex lock(mgr.mutex); ^ C:\libs\nana\source\internationalization.cpp: In lambda function: C:\libs\nana\source\internationalization.cpp:274:22: error: 'recursive_mutex' is not a member of 'std' std::lock_guardstd::recursive_mutex lockgd(eval_mgr.mutex); ^ C:\libs\nana\source\internationalization.cpp:274:22: error: 'recursive_mutex' is not a member of 'std' C:\libs\nana\source\internationalization.cpp:274:42: error: template argument 1 is invalid std::lock_guardstd::recursive_mutex lockgd(eval_mgr.mutex); ^ C:\libs\nana\source\internationalization.cpp:274:50: error: invalid type in declaration before '(' token std::lock_guardstd::recursive_mutex lockgd(eval_mgr.mutex); ^ C:\libs\nana\source\internationalization.cpp:274:60: error: 'struct nana::internationalization_parts::eval_manager' has no member named 'mutex' std::lock_guardstd::recursive_mutex lockgd(eval_mgr.mutex); ^ C:\libs\nana\source\internationalization.cpp: In function 'void nana::internationalization_parts::use_eval()': C:\libs\nana\source\internationalization.cpp:286:20: error: 'recursive_mutex' is not a member of 'std' std::lock_guardstd::recursive_mutex lock(mgr.mutex); ^ C:\libs\nana\source\internationalization.cpp:286:20: error: 'recursive_mutex' is not a member of 'std' C:\libs\nana\source\internationalization.cpp:286:40: error: template argument 1 is invalid std::lock_guardstd::recursive_mutex lock(mgr.mutex); ^ C:\libs\nana\source\internationalization.cpp:286:46: error: invalid type in declaration before '(' token std::lock_guardstd::recursive_mutex lock(mgr.mutex); ^ C:\libs\nana\source\internationalization.cpp:286:51: error: 'struct nana::internationalization_parts::eval_manager' has no member named 'mutex' std::lock_guardstd::recursive_mutex lock(mgr.mutex); ^ CMakeFiles\nana.dir\build.make:187: recipe for target 'CMakeFiles/nana.dir/source/internationalization.cpp.obj' failed mingw32-make[2]: *** [CMakeFiles/nana.dir/source/internationalization.cpp.obj] Error 1 CMakeFiles\Makefile2:66: recipe for target 'CMakeFiles/nana.dir/all' failed mingw32-make[1]: *** [CMakeFiles/nana.dir/all] Error 2 Makefile:126: recipe for target 'all' failed mingw32-make: *** [all] Error 2

This is hard to explain. I open up the Notepad demo app. If I cycle between a, s, and d, the text cursor will start jumping down and up and left and right and inserting newlines. Pressing the space tends to move up a line.

In the place_login demo app, doing the same thing looks fine. However:

1. If I select all the text and start typing, it will be prepended to the beginning instead of replacing the selected text.
2. If I prepend text to the beginning and cycle through a, s, and d again, the text cursor will gradually move to the right.

Also, API::exit doesn't seem to exit anything. The window just stays there.

I love Nana, but this is just insane.

the code below not works as expected, after the add file button get clicked and choosen a file, the label do not shows.

int main()
{
	using namespace nana;
	form fm;
	//It's unnecessary to specify a rectangle if useing
	//layout management.
	label lb1{ fm, u8"l1" }, lb2{ fm,u8"l2" }, lb3{ fm, u8"l2" }, lb4{ fm, u8"l3" };
	lb1.text_align(nana::align::center, nana::align_v::center);
	lb2.text_align(nana::align::center, nana::align_v::center);
	lb3.text_align(nana::align::center, nana::align_v::top);
	lb4.text_align(nana::align::center, nana::align_v::center);
	place layout(fm);
	button bt2{ fm ,u8"add file" };
	layout.div("<l4_1 vert gap=2>");
	std::set<std::string> attachments;
	layout["l4_1"] << bt2;
	bt2.events().click([&] {
		nana::filebox fb(true);
		if (fb()) {
			//attachments.insert(fb.file());
			nana::label tmp{ fm, fb.file() };
                       //static nana::label tmp{ fm, fb.file() };   // this line works,  but can only add one file
			layout["l4_1"] << tmp;
			layout.collocate();
		}
	});
	layout.collocate();
	fm.show();
	exec();
}

I thought the code above should work due to the right value reference of cpp 11, is this a bug, or i was wrong on the usage of right value reference?

while building with gcc 7 I got this error

[ 98%] Building CXX object CMakeFiles/BoardPlatformerClient.dir/main.cpp.o
In file included from /usr/include/c++/7.1.1/functional:64:0,
                 from /home/msca8h/projects/board_platformer/src/client/nana/include/nana/gui/detail/general_events.hpp:21,
                 from /home/msca8h/projects/board_platformer/src/client/nana/include/nana/gui/programming_interface.hpp:17,
                 from /home/msca8h/projects/board_platformer/src/client/nana/include/nana/gui/wvl.hpp:18,
                 from /home/msca8h/projects/board_platformer/src/client/nana/include/nana/gui.hpp:1,
                 from /home/msca8h/projects/board_platformer/src/client/main.cpp:1:
/usr/include/c++/7.1.1/bits/stl_algo.h:3719:5: error: redefinition of ‘template<class _Tp> constexpr const _Tp& std::clamp(const _Tp&, const _Tp&, const _Tp&)’
     clamp(const _Tp& __val, const _Tp& __lo, const _Tp& __hi)
     ^~~~~
In file included from /home/msca8h/projects/board_platformer/src/client/nana/include/nana/deploy.hpp:20:0,
                 from /home/msca8h/projects/board_platformer/src/client/nana/include/nana/paint/../basic_types.hpp:16,
                 from /home/msca8h/projects/board_platformer/src/client/nana/include/nana/paint/graphics.hpp:18,
                 from /home/msca8h/projects/board_platformer/src/client/nana/include/nana/gui/effects.hpp:15,
                 from /home/msca8h/projects/board_platformer/src/client/nana/include/nana/gui/programming_interface.hpp:16,
                 from /home/msca8h/projects/board_platformer/src/client/nana/include/nana/gui/wvl.hpp:18,
                 from /home/msca8h/projects/board_platformer/src/client/nana/include/nana/gui.hpp:1,
                 from /home/msca8h/projects/board_platformer/src/client/main.cpp:1:
/home/msca8h/projects/board_platformer/src/client/nana/include/nana/stdc++.hpp:151:21: note: ‘template<class T> constexpr const T& std::clamp(const T&, const T&, const T&)’ previously declared here
  constexpr const T& clamp(const T& v, const T& lo, const T& hi)
                     ^~~~~
make[2]: *** [CMakeFiles/BoardPlatformerClient.dir/build.make:63: CMakeFiles/BoardPlatformerClient.dir/main.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:68: CMakeFiles/BoardPlatformerClient.dir/all] Error 2
make: *** [Makefile:130: all] Error 2

is this because I'm using a new compiler? or compiler flags perhaps?

let's say widgets are stored in a container like that: vector<vector< unique_ptr<textbox> >> _someContainer; registering an event handler: _someContainer[var1][var2]->events().text_changed([](const nana::arg_textbox& texev)->void { //I can get a widget self texev.widget......; //but how can I get the indexes var1 and var2? })

In Delphi VCL (and Lazarus LCL) all widgets has .tag field of type integer. Does NANA have a mechanism of a similar purpose? Maybe use the tooltip string to store special information? Inherit from the desired class and add your own fields? I don't want to look through the entire container and compare pointers to find the desired widget. It looks silly. It is not advisable to perform cumbersome calculations in a frequently called handler. Does NANA have ready tools?

The library does a good job to provide a mechanism for customizing widget appearance, with the various custom renderers, and the scheme object that each widget has.

Unfortunately, that's currently incomplete due to a few omissions. Most importantly, there's no way to change the colors of tooltips and scrollbars. I have created an interface that responds to the system color theme (dark/light), and I was forced to use an ugly hack in scroll.cpp to make scrollbars use dark or light colors, depending on the parent's bgcolor. And I gave up trying to change to colors of tooltips. The library should provide a mechanism for changing scrollbar and tooltip colors (maybe a global scheme object for each, for example).

Also, another issue is the lack of a custom renderer for the listbox. My interface uses a custom renderer for comboxes in dark mode, but I can't do that for listboxes, which results in an inconsistent look (I had to use an ugly hack in listbox.cpp as a workaround).

Not sure why there's any support for char8_t variants, but this definitely breaks when compiled with MSVC C++20:

class renderer : public nana::menu::renderer_interface
{
	using color_rgb = ::nana::color_rgb;
public:
	renderer(const nana::pat::cloneable<renderer_interface>& rd)
		: reuse_(rd) //Reuses the current renderer
	{}
private:
	void background(graph_reference graph, nana::window wd) override
	{
		graph.rectangle(true, nana::colors::white);
		graph.rectangle(false, static_cast<color_rgb>(0x5DC1AC));
	}

	void item(graph_reference graph, const nana::rectangle& r, const attr& atr) override
	{
		if (state::active == atr.item_state)
			graph.rectangle(r, true, static_cast<color_rgb>(0x9ADCCA));
	}

	void item_image(graph_reference graph, const nana::point& pos, unsigned image_px, const nana::paint::image& img) override
	{
		reuse_->item_image(graph, pos, image_px, img);
	}

	void item_text(graph_reference graph, const nana::point& pos, const std::string& text, unsigned pixels, const attr& atr) override
	{
		reuse_->item_text(graph, pos, text, pixels, atr);
	}

        //so for some reason we need to fill this when compiling with C++20, but "text" is always garbage
	void item_text(graph_reference graph, const nana::point& pos, std::u8string_view text, unsigned pixels, const attr& atr) override
	{
		reuse_->item_text(graph, pos, text, pixels, atr);
	};

	void sub_arrow(graph_reference graph, const nana::point& pos, unsigned pixels, const attr& atr) override
	{
		reuse_->sub_arrow(graph, pos, pixels, atr);
	}
private:
	nana::pat::cloneable<renderer_interface> reuse_;
};

int main()
{
	nana::form fm;
	fm.caption("menu test");

	nana::menubar menubar;
	nana::menu* filemenu = nullptr;

	menubar.create(fm);

        //add menu
	filemenu = &menubar.push_back("File");
	
        //set menu renderer
        filemenu->renderer(renderer(filemenu->renderer()));
	
        //fill with something to look at
        filemenu->append("New", [](nana::menu::item_proxy& ip) {});
	filemenu->append("Open", [](nana::menu::item_proxy& ip) {});
	filemenu->append("Save", [](nana::menu::item_proxy& ip) {});
	filemenu->append("Save As", [](nana::menu::item_proxy& ip) {});
	filemenu->append("Export As", [](nana::menu::item_proxy& ip) {});
	filemenu->append("Close", [](nana::menu::item_proxy& ip) {});
	filemenu->append_splitter();
	filemenu->append("Exit", [](nana::menu::item_proxy& ip) {});


	fm.show();
	nana::exec();
	return 0;
}

I get an exception when trying to read or use text.

When I tried peeking into it, the contents appear to be garbage, and the length was 7824718.

This only happens when using custom renderers.

I'm not sure where the garbage is coming from, but a nice fix would be to remove this overload entirely, since char8_t variants aren't exactly useful in the current standard and the other overload worked just fine before C++20. And, to me, it also makes no sense to have two pure virtual overloads for the same exact purpose.

Added a new function to textbox and text_editor so that the border that is shown when the widget is clicked on can be disabled. The need for this was discussed in #656.

Example use to disable it:

form fm;
textbox tb{ fm };

tb.enable_border_focused(false);

The name of the function may need to be changed though, to maybe something like enable_focused_border_when_clicked, so it's more clear.

Currently on the Windows platform, window icons must either be a .ico file, a ICO encoded buffer or a resource icon.

To me, this doesn't make much sense, as the Win32 API easily supports creating icons on the fly straight from pixel data.

So in this PR I added support for creating icons directly from the pixel data stored in nana::paint::image. The point of this is that now one can easily set any bmp, png or jpeg (provided png and jpeg are enabled, respectively) as icons as well.

On that note I also wanted to say that the pixel buffer can be quite difficult to get pixel data from. Maybe the API could be improved in that regard.