U++ Forum - RDF feed
type: channel
description: Main place for discussions about U++ cross platform development framework.
items: 2019.2 rc5
items: Re: 2019.2 (pre)released

2019.2 rc5
type: item
description: Here we go. https://sourceforge.net/projects/upp/files/upp/2019.2/ (pre)release: I will announce on sf.net after a couple of days without serious bug reports... EDIT: OK, it is now rc5... Core Allocator huge block handling optimized, memory consumption improved in specific cases Index refactored to reduce sizeof and improve performance in specific cases Introduced workaround for Mingw TLS performance issue pick/clone semantics refined in several places Random algorithm changed to xoshiro256** Uuid generation optimized Fast U++ allocator is now used internally where possible even if standard allocator us used for new/delete (with USEMALLOC flag) pick/clone refinements Value::Compare optimized for standard types Core/SSH: A synchronization issue is fixed with socket waits. 3 new fingerprint methods are added (md5, sha1, sha256). Password change request and event is implemented. authentiaction-less connection is now possible. SshShell can now set terminal modes. Graphics SVG parser improvements GLCtrl new method ExecuteGL to execute code with correct GL context Font metrics optimized for MingW with TLS optimization workaround CtrlLib ArrayCtrl sorting improved CtrlMapper small helper class DropList supports Add with initializer_list FileSelButton WhenSelected Event FileSel has now more sorting options, PreSelect now supports Save As too Ide Console output now supports search Font settings 'set to defaults' button Debugger now has arrow buttons to change frame without dropping the list New GUI patch tool GDB debugger frontend now has memory tab Icon designer export to .png now exports uhd/dark variants too Main config dialog now can drag/drop (or move) lines Run options dialog got new buttons to insert file path / directory path into commandline args pkg-config support
creator: mirek
date: 2019-10-21T09:57:03-00:00

Re: 2019.2 (pre)released
type: item
description: Thank you for your efforts! As a side note, Core/SSH package is also updated: - A synchronization issue is fixed with socket waits. - 3 new fingerprint methods are added (md5, sha1, sha256). - Password change request and event is implemented. - authentiaction-less connection is now possible. - SshShell can now set terminal modes. - Docs are updated accordingly. Also There is a minor annoyance with Glib2: I get a lot of deprecation messages for glib2 (2.62) types: /usr/include/glib-2.0/glib/gtypes.h:549:26: bilgi: declared here 549 | typedef struct _GTimeVal GTimeVal GLIB_DEPRECATED_TYPE_IN_2_62_FOR(GDateTime); Nothing big, but bloats the error console on up-to-date setups. Best regards, Oblivion
creator: Oblivion
date: 2019-10-21T10:47:55-00:00

Re: 2019.2 (pre)released
type: item
description: Updated; i will ignore glib warning for now, as I am working on gtk3 for the next release. Mirek
creator: mirek
date: 2019-10-21T10:51:16-00:00

Re: 2019.2 (pre)released
type: item
description: Hi Mirek, Thanks! I have been waiting for this release... Unfortunately, once I now have it and started to migrate to it, I stumbled across a problem: My application rendering charts crashes after a few hundred or a few thousand times after rendering an image (well, a very LARGE IMAGE of 9880 x 10758 pixels) with BufferPainter. I discovered this in x64 release mode and reproduced in debug mode for the backtrace below. Platform: Windows 10 Pro x64, MSBT19x64, latest upp -- the release 2019.2 (13648). Here's the backtrace: Upp::Dbl_Unlink<Upp::BlkHeader_<256> >(x=1b7948c3840->{ prev=ff4b6644ff4b6644, next=ff526e48ff4b6644, prev_size=26180, size=65355, free=1, last=1, heap=ff4b6644ff4b6644 }) at C:\upp-13648\uppsrc\Core\Util.h 251 Upp::BlkHeader_<256>::UnlinkFree() at C:\upp-13648\uppsrc\Core\HeapImp.h 48 Upp::BlkHeap<Upp::Heap::LargeHeapDetail,256>::Free(h=1b7948c5040->{ prev=dcc, next=1b7c89aaee0, prev_size=24, size=15, free=0, last=1, heap=1b78f94d590 }) at C:\upp-13648\uppsrc\Core\HeapImp.h 243 Upp::Heap::LFree(ptr=1b7948c5050) at C:\upp-13648\uppsrc\Core\lheap.cpp 151 Upp::Heap::Free(ptr=1b7948c5050) at C:\upp-13648\uppsrc\Core\sheap.cpp 248 Upp::MemoryFree_(ptr=1b7948c5050) at C:\upp-13648\uppsrc\Core\sheap.cpp 363 Upp::MemoryFree(ptr=1b7948c5070) at C:\upp-13648\uppsrc\Core\heapdbg.cpp 145 Upp::Rasterizer::AddCells(y=1993, n=1) at C:\upp-13648\uppsrc\Painter\Rasterizer.cpp 97 Upp::Rasterizer::LineRaw(x1=0, y1=510208, x2=0, y2=0) at C:\upp-13648\uppsrc\Painter\Rasterizer.cpp 275 Upp::Rasterizer::CvLine(x1=0, y1=1993, x2=0, y2=0) at C:\upp-13648\uppsrc\Painter\RasterizerClip.cpp 11 Upp::Rasterizer::LineClip(x1=-51570.6378196279, y1=1993, x2=-53122.6291349367, y2=0) at C:\upp-13648\uppsrc\Painter\RasterizerClip.cpp 41 Upp::Rasterizer::Line(p=39d391ce78->{ x=-63112.5752626844, y=-12828.6559571624 }) at C:\upp-13648\uppsrc\Painter\RasterizerClip.cpp 100 Upp::BufferPainter::RenderPathSegments(g=1b7915676e0->{ }, path=1b7948293a0->{ vector=1b7917e71e0 "", items=120 'x'…
creator: Tom1
date: 2019-10-21T13:40:59-00:00

Re: 2019.2 (pre)released
type: item
description: Mirek, Now I went back and encountered similar issues on U++ 13068 using MSBT17x64 too. (The reason I have not discovered this problem before, is probably that I have not had this large images to render until now.) This time it crashed while my program called SetSurface(), but stack trace showed crash again in Upp::Dbl_Unlink(). Is this possibly an allocator issue, or could I have a very strange bug in my code? Debugger does not report any memory leaks if I exit the application before it crashes. Best regards, Tom
creator: Tom1
date: 2019-10-21T14:08:50-00:00

Re: 2019.2 (pre)released
type: item
description: Tom1 wrote on Mon, 21 October 2019 16:08 Mirek, Now I went back and encountered similar issues on U++ 13068 using MSBT17x64 too. (The reason I have not discovered this problem before, is probably that I have not had this large images to render until now.) This time it crashed while my program called SetSurface(), but stack trace showed crash again in Upp::Dbl_Unlink(). Is this possibly an allocator issue, or could I have a very strange bug in my code? Debugger does not report any memory leaks if I exit the application before it crashes. Best regards, Tom Well, that is weird indeed as 13068 is old allocator... So maybe, just maybe it is not allocator problem after all. Can you post trace for 13068 too please? Mirek
creator: mirek
date: 2019-10-21T14:35:16-00:00

Re: 2019.2 (pre)released
type: item
description: If it would be possible to catch again the crash through AddCells (in 2019.2), could you switch in debugger to that frame and tell me the value the debugger reports for "a.alloc" ? Mirek
creator: mirek
date: 2019-10-21T15:02:50-00:00

Re: 2019.2 (pre)released
type: item
description: OK. I will try this tomorrow. Thanks, Tom
creator: Tom1
date: 2019-10-21T16:05:13-00:00

Re: 2019.2 (pre)released
type: item
description: mirek wrote on Mon, 21 October 2019 17:02 If it would be possible to catch again the crash through AddCells (in 2019.2), could you switch in debugger to that frame and tell me the value the debugger reports for "a.alloc" ? Mirek Also.. could you please use "Copy backtrace of all threads" for both U++ versions? (I would like to know what other threads are doing...)
creator: mirek
date: 2019-10-22T07:18:53-00:00

Re: 2019.2 (pre)released
type: item
description: Oblivion wrote on Mon, 21 October 2019 12:47 There is a minor annoyance with Glib2: I get a lot of deprecation messages for glib2 (2.62) types: /usr/include/glib-2.0/glib/gtypes.h:549:26: bilgi: declared here 549 | typedef struct _GTimeVal GTimeVal GLIB_DEPRECATED_TYPE_IN_2_62_FOR(GDateTime); Nothing big, but bloats the error console on up-to-date setups. OK, so as we have to investigate issue reported by Tom error anyway, we might try to fix this as well. Unfortunately, it seems like internal inconsistency of gtk2 dev libraries (AFAIK, I do not even use GTimeVal anywhere). Unfortunately, this error does not happend on any of distros I have available, so it is a bit hard for me to fix, but I guess we should fix it by specifying max gtk2 version somehow, e.g. -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_60 in compiler flags or perhaps even before gtk/glib include (that is prefered IMO) or by -Wno-deprecated-warnings in compiler flags. https://tecnocode.co.uk/2019/08/24/gtimeval-deprecation-in-g lib-2-61-2/ Mirek https://github.com/clearlinux/clr-installer/pull/545
creator: mirek
date: 2019-10-22T07:46:39-00:00

Re: 2019.2 (pre)released
type: item
description: Hi, I think I'm getting closer to a solution: First, I think it is not the allocator as USEMALLOC crashes too. So, I guess this is good news. Anyway, it seems clear is that the heap gets corrupted somehow. The issue disappears if I use: BufferPainter bpainter(ib); in my rendering routine instead of: bpainter.Create(ib); along with the class wide BufferPainter. -- Resizing the window very easily causes the crash. Resizing the window also resizes/re-allocates the ImageBuffer used for rendering. This imagebuffer is associated with the BufferPainter through Create(ib). Could this be the real issue? If so, how can I go around it? I will now get some MT backtraces to show... Best regards, Tom
creator: Tom1
date: 2019-10-22T08:49:15-00:00

Re: 2019.2 (pre)released
type: item
description: Mirek, Here's one backtrace for 2019.2. They are different for each crash. ---------------------------------- Thread ID: 0xfa0 Upp::Dbl_Unlink<Upp::BlkHeader_<256> >(x=1eed9c1f840->{ prev=ff182412ff0f1b0c, next=ff15210dff182412, prev_size=5387, size=65291, free=1, last=1, heap=ff0f1b0cff091408 }) Upp::BlkHeader_<256>::UnlinkFree() Upp::BlkHeap<Upp::Heap::LargeHeapDetail,256>::Free(h=1eed9c20340->{ prev=6cc, next=1ee90d31050, prev_size=11, size=8, free=0, last=0, heap=1eed4fed460 }) Upp::Heap::LFree(ptr=1eed9c20350) Upp::Heap::Free(ptr=1eed9c20350) Upp::MemoryFree_(ptr=1eed9c20350) Upp::MemoryFree(ptr=1eed9c20370) Upp::Vector<Upp::Ctrl::MoveCtrl>::RawFree(ptr=1eed9c20370->{ ctrl={ prec=1eed6a40090 }, from={ left=2297, top=1995, right=2325, bottom=2035 }, to={ left=3812, top=1995, right=3840, bottom=2035 } }) Upp::Vector<Upp::Ctrl::MoveCtrl>::Free() Upp::Vector<Upp::Ctrl::MoveCtrl>::Clear() Upp::AMap<Upp::Ctrl *,Upp::Ctrl::MoveCtrl,Upp::Vector<Upp::Ctrl::MoveCtrl> >::Clear() Upp::Ctrl::SyncMoves() Upp::Ctrl::WndProc(hWnd=3b04fe->{ unused=?? }, message=3, wParam=0, lParam=2949120) CallWindowProcW() SendMessageW() GetWindowTextW() MapWindowPoints() IsCompositionActive() IsCompositionActive() GetWindowTextW() Upp::Ctrl::WindowProc(message=71 'G', wParam=0, lParam=592725532528) Upp::TopWindow::WindowProc(message=71 'G', wParam=0, lParam=592725532528) Upp::Ctrl::WndProc(hWnd=3b04fe->{ unused=?? }, message=71 'G', wParam=0, lParam=592725532528) CallWindowProcW() DispatchMessageW() MBToWCSEx() KiUserCallbackDispatcher() NtUserMessageCall() GetWindowTextW() MapWindowPoints() IsCompositionActive() Ordinal96() IsCompositionActive() IsCompositionActive() GetWindowTextW() Upp::Ctrl::WindowProc(message=274, wParam=61488, lParam=14944857) Upp::TopWindow::WindowProc(message=274, wParam=61488, lParam=14944857) Upp::Ctrl::WndProc(hWnd=3b04fe->{ unused=?? }, message=274, wParam=61488, lParam=14944857) CallWindowProcW() DispatchMessageW() IsWindowVisible() KiUserCallbackDispatcher() NtU…
creator: Tom1
date: 2019-10-22T09:03:14-00:00

Re: 2019.2 (pre)released
type: item
description: Hi, Here's the backtrace for 13068: ---------------------------------- Thread ID: 149c3f0 Upp::Dbl_Unlink<Upp::Heap::DLink>(x=14fc259ef30->{ next=ff182616ff152412, prev=ff1a2616ff172212 }) Upp::Heap::DLink::Unlink() Upp::Heap::DivideBlock(b=14fc259ef30->{ next=ff182616ff152412, prev=ff1a2616ff172212 }, size=4016) Upp::Heap::TryLAlloc(ii=38 '&', size=4016) Upp::Heap::LAlloc(size=72cf1d1a0->4016) Upp::Heap::AllocSz(sz=72cf1d1a0->4016) Upp::MemoryAlloc_(sz=4016) Upp::MemoryAlloc(size=3752) operator new[](size=3752) Upp::Buffer<Upp::RGBA>::Alloc(size=938) Upp::RasterEncoder::Create(sz=72cf1d2d8->{ cx=938, cy=2 }) Upp::RasterEncoder::Create(sz=72cf1d330->{ cx=938, cy=2 }, pal_raster=72cf1d510->{ }) Upp::Rescale(tgt=72cf1d560->{ size={ cx=938, cy=2 }, dots={ cx=0, cy=0 }, hotspot={ x=0, y=0 }, line=7ff78094ff18, scanline={ ptr=0?? }, line_bytes=-1011478400, h={ ptr=0 }, palette={ ptr=0 }, palette_cv={ ptr=0 }, format={ type=9, rmask=7, gmask=2128677031, bmask=32759, rpos=2, gpos=1, bpos=0, apos=3 } }, tsz=72cf1d548->{ cx=938, cy=2 }, src=72cf1d510->{ }, src_rc=72cf1d8d8->{ left=2, top=0, right=18, bottom=2 }, progress=72cf1d540->{ ptr=0 }) Upp::Rescale(src=72cf1d8e8->{ data=14ffa1433a0 }, sz=72cf1d690->{ cx=938, cy=2 }, src_rc=72cf1d8d8->{ left=2, top=0, right=18, bottom=2 }, progress=72cf1d688->{ ptr=0 }) Upp::ChImageMaker::Make() Upp::scImageMaker::Make(object=14fc3b610a0->{ data=0 }) Upp::LRUCache<Upp::Image,Upp::String>::Get(m=72cf1d808->{ }) Upp::MakeImage__(m=72cf1d8c8->{ }, paintonly=0) Upp::MakeImage(m=72cf1d8c8->{ }) Upp::ChDraw(w=72cf1eec0->{ }, x=2, y=0, cx=938, cy=2, img=72cf1d958->{ data=14ffa1433a0 }, src=72cf1dcb8->{ left=2, top=0, right=18, bottom=2 }) Upp::StdChLookFn(w=72cf1eec0->{ }, r=72cf1e008->{ left=0, top=0, right=942, bottom=1590 }, v=72cf1df98->{ data={ len=0, s=3??, chr=72cf1df98 "`\031MO\001", ptr=14fc24d1960 "x%\025\177", wptr=14fc24d1960, qptr=14fc24d1960, v=72cf1df98, w=72cf1df98, q=72cf1df98 }, svo=7ff78069cfe0 }, op=2) Upp::sChOp(w=72cf…
creator: Tom1
date: 2019-10-22T09:10:20-00:00

Re: 2019.2 (pre)released
type: item
description: Mirek, I do not seem to be able to crash through AddCells(). Tried many times. BR, Tom
creator: Tom1
date: 2019-10-22T09:18:16-00:00

Re: 2019.2 (pre)released
type: item
description: Tom1 wrote on Tue, 22 October 2019 10:49 BufferPainter bpainter(ib); in my rendering routine instead of: bpainter.Create(ib); along with the class wide BufferPainter. ib is class wide too? (Just to be in sync, 'class wide' means it exists for more than one Paint invocations, correct?) Mirek
creator: mirek
date: 2019-10-22T09:37:39-00:00

Re: 2019.2 (pre)released
type: item
description: They both (ib and bpainter) are actually members of different classes, but both classes are continuously alive throughout the life of the window. BR, Tom EDIT: And yes, the same ib is used in bpainter many times over. Before each use, bpainter.Create(ib); is called. (Meanwhile, the ib may have been resized/reallocated between the calls.)
creator: Tom1
date: 2019-10-22T09:47:45-00:00

Re: 2019.2 (pre)released
type: item
description: Tom1 wrote on Tue, 22 October 2019 11:47 They both (ib and bpainter) are actually members of different classes, but both classes are continuously alive throughout the life of the window. BR, Tom Would it be possible to test with temporary ib? Just to get some clues... Also, obvious reason, is not it possible that bpainter gets used (any method called) between ib being resized and Create called? (As in it would be referencing old data of ImageBuffer). Is Finish called properly? Mirek
creator: mirek
date: 2019-10-22T09:51:04-00:00

Re: 2019.2 (pre)released
type: item
description: Idea to test: Start the program. After all is 'stable', place breakpoint at place where you resize ib (probably by ib.Create ?). Resize, breapoint hits. Remove it and place breakpoint at bpainter.Create and also into BufferPainter::RenderPath. Continue and check that RenderPath is not called before bpainter.Create...
creator: mirek
date: 2019-10-22T09:55:07-00:00

Re: 2019.2 (pre)released
type: item
description: Hi, Thanks! I will look into your suggestions next. Meanwhile, here's a "crashable" testcase: #include <CtrlLib/CtrlLib.h> #include <Painter/Painter.h> using namespace Upp; class BufferPainterCreateCrash: public TopWindow{ public: ImageBuffer ib; BufferPainter bpainter; Image largeimage; BufferPainterCreateCrash(){ Sizeable().MaximizeBox().MinimizeBox(); bpainter.PreClipDashed(); ImageBuffer lib(10000,10000); BufferPainter bp(lib); bp.Clear(LtGray()); largeimage=lib; } void Paint(Draw &draw){ SetSurface(draw,Rect(ib.GetSize()),ib,ib.GetSize(),Point(0,0)); } void Render(Point p){ // Use local bpainter below instead of bpainter.Create to avoid crash: //BufferPainter bpainter(ib); //bpainter.PreClipDashed(); bpainter.Create(ib); bpainter.EvenOdd(); bpainter.Co(); bpainter.Clear(White()); bpainter.Rectangle(0,0,GetSize().cx,GetSize().cy); bpainter.Fill(largeimage); int fh=StdFont().GetHeight(); bpainter.Text(10,fh,Format("Cursor now at %`, %`",p.x,p.y),StdFont()).Fill(Black()); bpainter.Text(10,2*fh,"Grab the window by the edge and resize wildly. Expect crash...",StdFont()).Fill(Black()); bpainter.Finish(); // Fast updates if(GetTopCtrl()&&GetTopCtrl()->GetHWND()){ ViewDraw draw(this); SetSurface(draw,Rect(ib.GetSize()),ib,ib.GetSize(),Point(0,0)); } // For slow / delayed updates use Refresh() instead: // Refresh(); } void Layout(){ ib.Create(GetSize()); Render(Point(0,0)); } void MouseMove(Point p, dword keyflags){ Render(p); } }; GUI_APP_MAIN { BufferPainterCreateCrash().Execute(); } Best regards, Tom
creator: Tom1
date: 2019-10-22T10:20:01-00:00

Re: 2019.2 (pre)released
type: item
description: mirek wrote on Tue, 22 October 2019 12:55 Idea to test: Start the program. After all is 'stable', place breakpoint at place where you resize ib (probably by ib.Create ?). Resize, breapoint hits. Remove it and place breakpoint at bpainter.Create and also into BufferPainter::RenderPath. Continue and check that RenderPath is not called before bpainter.Create... It takes quite a few repeats until it crashes, so I cannot get it to crash this way in near future. However, if crash is not required: This entered Create first and only thereafter to RenderPath. If GUI is single threaded, I do not think it should do it any other way. The testcase is logically pretty close to what I'm doing here, so let's focus on that for a while as it crashes very similarly, shall we? Best regards, Tom
creator: Tom1
date: 2019-10-22T10:37:16-00:00

Re: 2019.2 (pre)released
type: item
description: Tom1 wrote on Tue, 22 October 2019 12:37 The testcase is logically pretty close to what I'm doing here, so let's focus on that for a while as it crashes very similarly, shall we? Best regards, Tom Definitely, I have not hoped for testcase, that is perfect. Thank you. Mirek
creator: mirek
date: 2019-10-22T10:42:16-00:00

Re: 2019.2 (pre)released
type: item
description: mirek wrote on Tue, 22 October 2019 12:51 Tom1 wrote on Tue, 22 October 2019 11:47 They both (ib and bpainter) are actually members of different classes, but both classes are continuously alive throughout the life of the window. BR, Tom Would it be possible to test with temporary ib? Just to get some clues... Also, obvious reason, is not it possible that bpainter gets used (any method called) between ib being resized and Create called? (As in it would be referencing old data of ImageBuffer). Is Finish called properly? Mirek Temporary ib would change the rendering in a big way as it is my base for getting Paint and Render separated. While that would be a sensible explanation for what is happening here, I do not think it is possible for bpainter to be used when ib is out-of-order after resizing. As you can see from the testcase, Layout doing ib.Create calls Render doing bpainter.Create(ib) immediately. Best regards, Tom
creator: Tom1
date: 2019-10-22T10:51:21-00:00

Re: 2019.2 (pre)released
type: item
description: Quote: OK, so as we have to investigate issue reported by Tom error anyway, we might try to fix this as well. Unfortunately, it seems like internal inconsistency of gtk2 dev libraries (AFAIK, I do not even use GTimeVal anywhere). Unfortunately, this error does not happend on any of distros I have available, so it is a bit hard for me to fix, but I guess we should fix it by specifying max gtk2 version somehow, e.g. -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_60 in compiler flags or perhaps even before gtk/glib include (that is prefered IMO) or by -Wno-deprecated-warnings in compiler flags. https://tecnocode.co.uk/2019/08/24/gtimeval-deprecation-in-g lib-2-61-2/ Mirek https://github.com/clearlinux/clr-installer/pull/545 My workaround was to suppress the message in CtrlCore/Gtk.h This should be qualified though. IMO the auppression should be disabled in release mode. #ifdef __GNUC__ #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wdeprecated-declarations" #endif #include <gtk/gtk.h> #include <gdk/gdkkeysyms.h> #ifdef __GNUC__ #pragma GCC diagnostic pop #endif Best regards, Oblivion
creator: Oblivion
date: 2019-10-22T10:55:07-00:00

Re: 2019.2 (pre)released
type: item
description: Tom1 wrote on Tue, 22 October 2019 12:20 Hi, Thanks! I will look into your suggestions next. Meanwhile, here's a "crashable" testcase: Hopefully fixed - does not crash in trunk anymore. Can you please check the trunk in your application? Mirek
creator: mirek
date: 2019-10-22T11:51:45-00:00

Re: 2019.2 (pre)released
type: item
description: Oblivion wrote on Tue, 22 October 2019 12:55 Quote: OK, so as we have to investigate issue reported by Tom error anyway, we might try to fix this as well. Unfortunately, it seems like internal inconsistency of gtk2 dev libraries (AFAIK, I do not even use GTimeVal anywhere). Unfortunately, this error does not happend on any of distros I have available, so it is a bit hard for me to fix, but I guess we should fix it by specifying max gtk2 version somehow, e.g. -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_60 in compiler flags or perhaps even before gtk/glib include (that is prefered IMO) or by -Wno-deprecated-warnings in compiler flags. https://tecnocode.co.uk/2019/08/24/gtimeval-deprecation-in-g lib-2-61-2/ Mirek https://github.com/clearlinux/clr-installer/pull/545 My workaround was to suppress the message in CtrlCore/Gtk.h This should be qualified though. IMO the auppression should be disabled in release mode. #ifdef __GNUC__ #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wdeprecated-declarations" #endif #include <gtk/gtk.h> #include <gdk/gdkkeysyms.h> #ifdef __GNUC__ #pragma GCC diagnostic pop #endif Best regards, Oblivion Thank you, applied. I am not much worried about release here... This is temporary solution until the next release anyway.
creator: mirek
date: 2019-10-22T12:22:42-00:00

Re: 2019.2 (pre)released
type: item
description: Hi Mirek, Thanks for your prompt action on this. Now I have already left the office for today, but I will test it as soon as I get back there tomorrow. Thanks and best regards, Tom
creator: Tom1
date: 2019-10-22T12:33:23-00:00

Re: 2019.2 (pre)released
type: item
description: mirek wrote on Tue, 22 October 2019 14:51 Tom1 wrote on Tue, 22 October 2019 12:20 Hi, Thanks! I will look into your suggestions next. Meanwhile, here's a "crashable" testcase: Hopefully fixed - does not crash in trunk anymore. Can you please check the trunk in your application? Mirek Thanks Mirek! The fix works perfectly. Best regards, Tom
creator: Tom1
date: 2019-10-23T06:34:44-00:00