Yes, I meant SashPosition.
OK, I tried the following without much success. The Sash Position
is always set at 190, by itemSplitterWindow9->SplitHorizontally
(itemPanel10, itemPanel13, 190);
1. Increased the size of the wxSplitterWindows parent window to
500,500 and 600,600.
A call to itemSplitterWindow9->GetSashPosition returns 15
Still shows the sash position and near 0?
2. At the end of CreateControls function added
itemSplitterWindow9->SetSashPosition(100);
itemSplitterWindow9->UpdateSize();
A call to itemSplitterWindow9->GetSashPosition returns 15
Still shows the sash position and near 0?
3. Increased the size of the wxSplitterWindows parent window to
600,600 and added
itemSplitterWindow9->SetSashGravity(0.5);
itemSplitterWindow9->UpdateSize();
A call to itemSplitterWindow9->GetSashPosition returns 15
Shows the sash position something near normal, I guess its
own choice, this will not work because I would like to
catch the EVT_SPLITTER_SASH_POS_CHANGED event and use
this in the future to place the splitter position back to.
You said something about the size of the wxSplitterWindows being to
small, I have not changed this, it is the default.
I still think I am doing something wrong and any help for a work
around would be appreciated.
Jeff Downs
--- In anthemion-devtools%40yahoogroups.com">anthemion-devtools
yahoogroups.com, Julian Smart <julian...>
wrote:
>
> Hi Jeff,
>
> (I guess you mean SashPosition 
)
>
> Getting the sash set correctly can be a pain because of the order
in
> which windows are sized. The problem is that if a splitter is
created at
> a small size than the current sash position, the splitter
helpfully
> resets the sash position to fit the size - even if the splitter
will
> shortly be a bigger size. One trick is to create the splitter and
if
> necessary parent windows with a specific size, greater than the
sash
> position, so the splitter will never get too small for the sash.
You can
> also try to set the sash position after all other sizing has been
done
> (after window layout). See also wxSplitterWindow::UpdateSize for
control
> of when child size calculations are done (sometimes I add an
UpdateSize
> call after layout but before a window is shown, to avoid a visible
> update in idle time).
>
> We need some kind of fix for this long-term problem with
> wxSplitterWindow. One solution might be for the splitter to skip
its
> usual sash adjustment code within OnSize until the first idle
event has
> been received (and after that, do the OnSize processing as
before). We
> would need a bool variable to indicate the pre-idle state, so for
binary
> compatibility reasons any fix would probably need to be done in
2.9 (or
> in your local source code) and not the stable 2.8 branch, unless
an
> existing variable were hijacked, e.g. use a new m_dragMode value.
>
> Regards,
>
> Julian
>
> Jeff Downs wrote:
> >
>; > I have been working on Windows XP and just started to compile
and test
> > on Fedora 7 with wxGTK 2.8.4 static build. See the attached
> > DialogBlocks 4.15 (Unicode) version project file ATest1.pjd.
> > DialogBlocks shows the correct SlashPosition that I have set on
the
> > dialog ATestDialog, it also works fine on windows XP compiled
with
> > VC++ 6.0, but when I compile and run it on the Fedora 7 system
the
> > SlashPosition shows up as zero or at the top of the window, you
can
> > manually resize it. I also tried to set the SlashPosition at 0
the
> > default and it still does the same thing. This is just one
example of
> > many places in my project that this is happening.
> >
>; > I must be doing something wrong, would someone please take a
look at this.
> >
>; > Thanks,
> >
>; > Jeff Downs
> >
>; >
>
>
> --
> Julian Smart, Anthemion Software Ltd.
>; 28/5 Gillespie Crescent, Edinburgh, Midlothian, EH10 4HU
> www.anthemion.co.uk | +44 (0)131 229 5306
>; Tools for writers: www.writerscafe.co.uk
> wxWidgets RAD: www.anthemion.co.uk/dialogblocks
>
.
