1. RE Questions about IDE and perhaps Win32Lib
Ray wrote:
>Hi All
>I have been having great fun with IDE and Win32Lib.
>1. One thing that I have found is that it is difficult to know in advance
>how things will fit in a window with lots of controls, and with multi-tabs
>the problem can be even greater. Big ask coming up ...
>Ideally I would like to be able to cut and paste a control (especially a
>group control) from one tab to another (BTW the tabs are virtually full
>window size). I cannot find any way to achieve this inside IDE so this
>might be a request for a new feature. If such a feature is considered it
>might possibly be useful to allow multiple pastes (haven't actually had a
>need for this - just a simple MOVE is all that I really need) in which
>case the control numbering would need to be adjusted each time after the
>first.
This is on my ToDo list. Also to move a control from Window to Window.
Some people get around this problem by temporarily resizing their Design
window larger and moving the control out of the TabItem (or Group or
whatever) onto an empty space in Design, change the TabItem and move the
control into that tab. Then resize the Design window back to the original
size.
>2. I cannot understand what a ReBar is, can someone please explain to me.
A ReBar is a fancy ToolBar. If you use Internet Explorer, the bars where
"File","Edit","View","Favorites","Tools","Help" sit is a ReBarBand and so is
"Back","Forward","Stop" etc and "Address". You can resize the ReBarBand to
suit your needs. A ReBarBand itself isa member of ReBar.
>3. In Win32Lib a control can be declared as EITHER a number of pixels OR a
>proportion of the parent size e.g. .25 for a quarter. I tried to do this
>also in IDE but it didn't work. Is it possible to do this in IDE?
This is also on my ToDo list. The best you can do right now is use
"Alternate Positions" in Properties. You use the X,Y,CX,CY you use now to
move and resize the control. The downside is you will not see how the
controls actually look until you MenuRun or MenuTempRun. This is not a
trivial change basically because all the control movements are by pixel X,Y.
I have been successful at translating a percentage X and Y to Design but
when the control moves or resizes, I'm having problems adjusting the pixel
X,Y back to a percentage. I know, I know, this doesn't sound like a big deal
but it has been.
>My problem is that I am designing for a 1024x768 screen size but want to
>be able to have it work on any screen size and for everything to scale
>correctly. I don't mind calculating the correct font sizes etc myself.
Yes, I agree.
Sorry I can not help you on any of the following.
>How do other people deal with this? I see some windows that when resized a
>big gray area appears which is pretty useless.
>One thought that I had was to use say an 8 grid on 1024x768 and this could
>rescale to 6 or 10 or 12 for other screen sizes without any odd fractions
>developing. Fonts would also be changed by the same proportions so that
>the text filled buttons equally.
>The problem is that if a window has fonts suitable for a 800x600 screen
>size then the fonts are far to small on a 1280x960 screen size and if the
>font size is increased then the buttons will also need to be larger (in
>pixels).
>Ray Tomes
2. Re: RE Questions about IDE and perhaps Win32Lib
> Ray wrote:
>>3. In Win32Lib a control can be declared as EITHER a number of pixels OR a
>>proportion of the parent size e.g. .25 for a quarter. I tried to do this
>>also in IDE but it didn't work. Is it possible to do this in IDE?
Judith Evans wrote:
> This is also on my ToDo list. The best you can do right now is use
> "Alternate Positions" in Properties. You use the X,Y,CX,CY you use now to
> move and resize the control. The downside is you will not see how the
> controls actually look until you MenuRun or MenuTempRun. This is not a
> trivial change basically because all the control movements are by pixel X,Y.
> I have been successful at translating a percentage X and Y to Design but
> when the control moves or resizes, I'm having problems adjusting the pixel
> X,Y back to a percentage. I know, I know, this doesn't sound like a big deal
> but it has been.
Well if it is a function already in Win32Lib, why does IDE need to do
anything but make it available?
One possible problem, which may be what you are up against is that
percentages don't necessarily add up. For example 25% of 15 pixels would
be 4 to the nearest one, but 4 lots of 4 makes 16 and is a pixel to big.
So buttons may have cracks between or slightly overlap.
If this is your problem then I can offer you a solution. First convert
from x, y, cx, cy to x, y, (x+cx), (y+cy) and then proportion these by the
% and then convert back to x, y, cx, cy. Example:
x=.30, y=.10, cx=.06, cy=.03 ==> x=.30, y=.10, (x+cx)=.36, (y+cy)=.13 and
then for a 800x600 window this gives 240, 60, 288, 78 which are all
integers so it would have worked anyway.
But for a 1024x768 window 307.2, 76.8, 368.64, 99.84 which are then
converted to nearest integer giving 307, 77, 369, 100 and so you get
x=307, y=77, cx=62, cy=23.
What this method does is ensure that two object edges which fitted exactly
before still fit perfectly after scaling (whereas scaling x, y, cx, cy
will not achieve this). Previously identical sized objects may vary in
size by 1 pixel which should not be a problem. It can be avoided by very
careful selection of grid sizes to start with.
3. Re: RE Questions about IDE and perhaps Win32Lib
On Wed, 25 Jun 2003 17:20:35 +1200 (06/25/03 15:20:35)
, Ray Tomes <rtomes at ihug.co.nz> wrote:
>
>
[snip]
>
> Well if it is a function already in Win32Lib, why does IDE need to do
> anything but make it available?
>
> One possible problem, which may be what you are up against is that
> percentages don't necessarily add up. For example 25% of 15 pixels would
> be 4 to the nearest one, but 4 lots of 4 makes 16 and is a pixel to big.
> So buttons may have cracks between or slightly overlap.
I've been toying with the idea of allowing placement parameters specify
which control they are relative to. This means that we can place a ControlB
2 pixels to the right of ControlA and have its top aligned with ControlC.
I'm still working on a useful syntax for this.
--
cheers,
Derek Parnell
4. Re: RE Questions about IDE and perhaps Win32Lib
Derek wrote:
> I've been toying with the idea of allowing placement parameters specify
> which control they are relative to. This means that we can place a ControlB
> 2 pixels to the right of ControlA and have its top aligned with ControlC.
>
> I'm still working on a useful syntax for this.
This sort of stuff has been available under Linux for a long time. You might
have a look at Tcl/Tk; it's got a pretty nice system. So does wxWindows and
GTK.
A combination of button box sizers and flex grid sizers will often give you
what you are looking for:
http://inti.sourceforge.net/tutorial/libinti/cwbuttonboxes.html
http://wiki.wxpython.org/index.cgi/wxDesigner_20Sizer_20Tutorial
-- David Cuny
