Limiting resize for (scrolled) image display

If you are using the main C++ distribution of wxWidgets, Feel free to ask any question related to wxWidgets development here. This means questions regarding to C++ and wxWidgets, not compile problems.
User avatar
doublemax
Moderator
Moderator
Posts: 19114
Joined: Fri Apr 21, 2006 8:03 pm
Location: $FCE2

Re: Limiting resize for (scrolled) image display

Post by doublemax »

Aha! Looks like I missed something fundamental. What wx components must be constructed with new? Where do I find this in the documentation?
AFAIK there is no explicit information about this. Just think about the lifetime of any object. If you'd create a wxWindow on the stack, it would be destroyed when the function (e.g. the wxFrame constructor) ends. This wouldn't make sense.

More confusing may be the fact that there are many cases where you're not allowed to delete objects you created with new, because another object will take ownership of the pointer and delete it for you.
http://docs.wxwidgets.org/trunk/overvie ... etion.html

Start with studying the "minimal" sample. In the beginning it may be a little confusing, but you'll get a feeling for it quite quickly.
Use the source, Luke!
DaveNadler
Experienced Solver
Experienced Solver
Posts: 53
Joined: Thu Nov 17, 2011 2:13 pm

Re: Limiting resize for (scrolled) image display

Post by DaveNadler »

DaveNadler wrote:
doublemax wrote:A sizer always has to be constructed on the heap (with "new"). As you wrote "&sizer" you probably didn't.
Aha! Looks like I missed something fundamental. What wx components must be constructed with new? Where do I find this in the documentation? Thanks!
Doublemax, it would be great, at if you could point me to some documentation on this. Clearly lots of wx components can be created on the stack or as components of other objects, but which? Any documentation discussion of object lifetimes?
Thanks!
DaveNadler
Experienced Solver
Experienced Solver
Posts: 53
Joined: Thu Nov 17, 2011 2:13 pm

Re: Limiting resize for (scrolled) image display

Post by DaveNadler »

doublemax wrote:Ok, i understand. Hopefully adding the 64bit compiler to VS2010 works.
Thanks Doublemax! Good news, bad news. Aftering installing the 64-bit compiler via adding the SDK...
An individual project can be converted albeit with a bunch of warnings:
Image
Trying to load the group solution or workspace SAMPLES.DSW fails; each included project fails with:
Image
User avatar
eranon
Can't get richer than this
Can't get richer than this
Posts: 867
Joined: Sun May 13, 2012 11:42 pm
Location: France
Contact:

Re: Limiting resize for (scrolled) image display

Post by eranon »

Hello,

About you lack of VS's 64-bit tools:
I recently encountered close to the same situation with Visual Studio 2008 Express (even if it was not in XP, doesn't matter): no 64-bit toolchain with the Express edition... So, I spent some hours to reach the right way to work around this limitation and found some (not a lot) pages describing a working way: the tip is to obtain the required toolset from the Windows SDK itself. Here is one of the page describing how to do step by step: https://jenshuebel.wordpress.com/2009/0 ... t-targets/

About the heap and stack:
The fact the sizers and all GUI components are to be allocated on heap is not explicitely explained in the wxWidgets documentation, but it's not wxWidgets specific. It's a matter of instance lifetime... If you allocate a sizer on the stack it will be dead (deallocated in memory, releasing the space it took) at the end of the function allocating it (ie. here at the end of the frame's constructor), while when you allocate on the heap, it survives until you explicitely "delete" (the complementary of "new") it or it's implicitely deleted by wxWidgets itself (concretely when your app is closed and the frame is destroyed).
[Ind. dev. - wxWidgets 3.0/3.1 under "Win 7 64-bit, TDM64-GCC" + "OS X 10.9, LLVM Clang"]
User avatar
doublemax
Moderator
Moderator
Posts: 19114
Joined: Fri Apr 21, 2006 8:03 pm
Location: $FCE2

Re: Limiting resize for (scrolled) image display

Post by doublemax »

An individual project can be converted albeit with a bunch of warnings:
These warnings are definitely not normal, but i have no idea what to do about them. Did you try loading one of the older project files?

If that all doesn't work, you could try building from the command line. ( Read <wxdir>/docs/msw/install.txt, search for "Microsoft Visual C++ Compilation" )

And as a last resort: I think there is preliminary cmake support in the latest development version on GIT. I don't know in what state that is, but maybe it can generate project files that don't contain the 64bit configurations.
Use the source, Luke!
User avatar
doublemax
Moderator
Moderator
Posts: 19114
Joined: Fri Apr 21, 2006 8:03 pm
Location: $FCE2

Re: Limiting resize for (scrolled) image display

Post by doublemax »

But setting the SetMaxClientSize for the frame won't work, because the maximum required size depends on the scroll situation.
I just tested this under wx 2.8.12 and you're right, the behavior is indeed different there. The client size would have to be bitmap size + size of the scrollbars in order to make the window so big that the scrollbars disappear. wx3.x seems to have smarter code that takes that into consideration.

So it would be preferable if you get wx3.x to work, but if you wanted to continue with 2.8.12 you'd really need a size event handler that checks if scrollbars are visible and set the maximum size accordingly.
Use the source, Luke!
DaveNadler
Experienced Solver
Experienced Solver
Posts: 53
Joined: Thu Nov 17, 2011 2:13 pm

Re: Limiting resize for (scrolled) image display

Post by DaveNadler »

eranon wrote:...About you lack of VS's 64-bit tools... the tip is to obtain the required toolset from the Windows SDK itself.
Thanks, already done per Doublemax's hint several posts above.
eranon wrote:About the heap and stack:
The fact the sizers and all GUI components are to be allocated on heap is not explicitely explained in the wxWidgets documentation, but it's not wxWidgets specific. It's a matter of instance lifetime... If you allocate a sizer on the stack it will be dead (deallocated in memory, releasing the space it took) at the end of the function allocating it (ie. here at the end of the frame's constructor), while when you allocate on the heap, it survives until you explicitely "delete" (the complementary of "new") it or it's implicitely deleted by wxWidgets itself (concretely when your app is closed and the frame is destroyed).
Obviously I'm not allocating things on the stack which need some lifetime. They were coded as members of window classes for example derived from wxFrame (for example sizer). The lack of documentation about object ownership and lifetime is more than a little bit worrying, as certainly many wx components can be (and often should be) allocated on stack or such...
DaveNadler
Experienced Solver
Experienced Solver
Posts: 53
Joined: Thu Nov 17, 2011 2:13 pm

Re: Limiting resize for (scrolled) image display

Post by DaveNadler »

doublemax wrote:More confusing may be the fact that there are many cases where you're not allowed to delete objects you created with new, because another object will take ownership of the pointer and delete it for you.
http://docs.wxwidgets.org/trunk/overvie ... etion.html
Thanks again doublemax, that link somewhat clarifies the situation for wxWindow derivatives. What about other components like sizers? Changing my code to new the sizer (sizer was a member of the wxFrame-derivative class, now the member is a pointer to sizer) had no effect.
User avatar
doublemax
Moderator
Moderator
Posts: 19114
Joined: Fri Apr 21, 2006 8:03 pm
Location: $FCE2

Re: Limiting resize for (scrolled) image display

Post by doublemax »

What about other components like sizers?
Sizers must be allocated on the heap, too. And normally you never have to delete them yourself (because they are either owned by a window or by another sizer. So they all get destroyed when the window gets destroyed.
Changing my code to new the sizer (sizer was a member of the wxFrame-derivative class, now the member is a pointer to sizer) had no effect.
You haven't shown your code yet. As already mentioned, i suggest to stick with my sample code for now. When you got that to work, you can fix your own code.
Use the source, Luke!
DaveNadler
Experienced Solver
Experienced Solver
Posts: 53
Joined: Thu Nov 17, 2011 2:13 pm

Re: Limiting resize for (scrolled) image display

Post by DaveNadler »

doublemax wrote:You haven't shown your code yet...
I cut this down to a minimal sample attached, if anybody wants to take a look...
Thanks!
Attachments
20180127_MapWinTest.zip
(37.22 KiB) Downloaded 70 times
User avatar
doublemax
Moderator
Moderator
Posts: 19114
Joined: Fri Apr 21, 2006 8:03 pm
Location: $FCE2

Re: Limiting resize for (scrolled) image display

Post by doublemax »

That looks unnecessarily complicated. What will be final app look like? Will there be any controls by the side of the bitmap or will it just display the bitmap and nothing else?
Use the source, Luke!
DaveNadler
Experienced Solver
Experienced Solver
Posts: 53
Joined: Thu Nov 17, 2011 2:13 pm

Re: Limiting resize for (scrolled) image display

Post by DaveNadler »

doublemax wrote:That looks unnecessarily complicated.
I'm open to suggestions! Anyway, most of the code is #if'd out attempts to get proper resize behavior....
doublemax wrote:What will be final app look like? Will there be any controls by the side of the bitmap or will it just display the bitmap and nothing else?
This is part of a much larger app (~150k lines C++). This window will only display the bitmap.
Last edited by DaveNadler on Sat Jan 27, 2018 8:56 pm, edited 1 time in total.
User avatar
doublemax
Moderator
Moderator
Posts: 19114
Joined: Fri Apr 21, 2006 8:03 pm
Location: $FCE2

Re: Limiting resize for (scrolled) image display

Post by doublemax »

It all depends on whether you manage to use wx 3.x, then you don't need all that code that sets a different client size based on the state of the scrollbars.
Use the source, Luke!
DaveNadler
Experienced Solver
Experienced Solver
Posts: 53
Joined: Thu Nov 17, 2011 2:13 pm

Re: Limiting resize for (scrolled) image display

Post by DaveNadler »

doublemax wrote:It all depends on whether you manage to use wx 3.x, then you don't need all that code that sets a different client size based on the state of the scrollbars.
The example I uploaded uses wx3.0.3 and I was still not able to get the resize to work correctly.
User avatar
eranon
Can't get richer than this
Can't get richer than this
Posts: 867
Joined: Sun May 13, 2012 11:42 pm
Location: France
Contact:

Re: Limiting resize for (scrolled) image display

Post by eranon »

DaveNadler wrote:Obviously I'm not allocating things on the stack which need some lifetime. They were coded as members of window classes...
Not necessarily! The pointers to the GUI components and any controls are not necessarily members of the frame. They are members only if you need to reach them during the frame's life.
[Ind. dev. - wxWidgets 3.0/3.1 under "Win 7 64-bit, TDM64-GCC" + "OS X 10.9, LLVM Clang"]
Post Reply