Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ Library support » U++ Widgets - General questions or Mixed problems » Understanding Frames
Understanding Frames [message #3851] Sat, 01 July 2006 00:09 Go to next message
brianE is currently offline  brianE
Messages: 13
Registered: June 2006
Promising Member
Oh dear, I hope you don't mind my questions. Each time someone explains something I do some experiments and find new things to ask about!

I have read the 'About Frames' article. I see the Cyan portion as the 'body' of the window and is called frame0. Then you 'insert' a frame (in Green) on the left which squashes frame0. So, what can I do with this green space? is it dead? can I add Ctrls to it? Can I do a BlackFrame or ButtonFrame to it? Do I refer to it as frame number 1?

Now we do different clever things with another frame. This time we 'add' so that it goes inside the 'body'. Is it, too, dead or can I play with it? Is it frame number 2?

What I want to do is split a window into this:
   +--------------+
   |              |
   +---+----------+
   |   |          |
   |   |          |
   |   |          |
   +---+----------+
The top portion always stays the same height, the left portion always stays the same width. And I will want to put things inside them. Do I use FrameTop and FrameLeft? If so how? Or is it LayoutFrameTop etc? I know that I don't want a splitter because that's moveable and I've learnt how to use that! Anyway, I'm sorry, but I am confused about Frames.

<off topic> I read in one of the posts about people coming to Upp and perhaps not staying or maybe they just didn't like to post. Maybe because I am new but I see that lots of people have looked at the topics I have started - and no, it wasn't me! Anyway, I think one needs patience and perseverance and one will overcome all the starting difficulties and reap the rewards.</off topic>

Once I have mastered these pesky frames I will want to talk about DragAndDrop! Are you ready? Wink

brianE
Re: Understanding Frames [message #3853 is a reply to message #3851] Sat, 01 July 2006 10:20 Go to previous messageGo to next message
forlano is currently offline  forlano
Messages: 1202
Registered: March 2006
Location: Italy
Senior Contributor
brianE wrote on Sat, 01 July 2006 00:09



What I want to do is split a window into this:
   +--------------+
   |              |
   +---+----------+
   |   |          |
   |   |          |
   |   |          |
   +---+----------+
The top portion always stays the same height, the left portion always stays the same width. And I will want to put things inside them. Do I use FrameTop and FrameLeft? If so how? Or is it LayoutFrameTop etc? I know that I don't want a splitter because that's moveable and I've learnt how to use that! Anyway, I'm sorry, but I am confused about Frames.


I cannot help you about frame as I've not yet really understood it. But if you want to design you window in some fixed manner perhaps the LabelBox can be enough. Drop as many you want on your layout. Resize them and put inside what you want. For this purpose I've neveer u8sed Frame.

Quote:


Once I have mastered these pesky frames I will want to talk about DragAndDrop! Are you ready? Wink

brianE



DragAndDrop is not yet supported but is in the ToDo list.
Luigi
Re: Understanding Frames [message #3855 is a reply to message #3853] Sat, 01 July 2006 13:56 Go to previous messageGo to next message
fudadmin is currently offline  fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania
Ultimate Contributor
Administrator
forlano wrote on Sat, 01 July 2006 09:20


I cannot help you about frame as I've not yet really understood it. But if you want to design you window in some fixed manner perhaps the LabelBox can be enough. Drop as many you want on your layout. Resize them and put inside what you want. For this purpose I've neveer u8sed Frame.

Luigi


Are we in trouble this week because Mirek is on holiday? Smile
Anyone else can explain frames?
My current upp Frames understanding is not far away from Luigi's apart from the fact that I use them only as ready-to-use decorated borders. And they are shared between widgets like Display...

As neutral positioning containers I usually use Ctrl, ParentCtrl or StaticRect or any Ctrls which have Add(Ctrl&... or AddChild(Ctrl*...

I can only guess that frames could be used for more clever positioning and decorating if used with multiple inheritance...

Has anyone used Frames as positioning container?

[Updated on: Sat, 01 July 2006 13:59]

Report message to a moderator

Re: Understanding Frames [message #3856 is a reply to message #3851] Sat, 01 July 2006 22:34 Go to previous messageGo to next message
Werner is currently offline  Werner
Messages: 234
Registered: May 2006
Location: Cologne / Germany
Experienced Member
brianE wrote on Sat, 01 July 2006 00:09

Oh dear, I hope you don't mind my questions. Each time someone explains something I do some experiments and find new things to ask about!

I have read the 'About Frames' article. I see the Cyan portion as the 'body' of the window and is called frame0. Then you 'insert' a frame (in Green) on the left which squashes frame0. So, what can I do with this green space? is it dead? can I add Ctrls to it? Can I do a BlackFrame or ButtonFrame to it? Do I refer to it as frame number 1?

Now we do different clever things with another frame. This time we 'add' so that it goes inside the 'body'. Is it, too, dead or can I play with it? Is it frame number 2?

What I want to do is split a window into this:
   +--------------+
   |              |
   +---+----------+
   |   |          |
   |   |          |
   |   |          |
   +---+----------+
The top portion always stays the same height, the left portion always stays the same width. And I will want to put things inside them. Do I use FrameTop and FrameLeft? If so how? Or is it LayoutFrameTop etc? I know that I don't want a splitter because that's moveable and I've learnt how to use that! Anyway, I'm sorry, but I am confused about Frames.

<off topic> I read in one of the posts about people coming to Upp and perhaps not staying or maybe they just didn't like to post. Maybe because I am new but I see that lots of people have looked at the topics I have started - and no, it wasn't me! Anyway, I think one needs patience and perseverance and one will overcome all the starting difficulties and reap the rewards.</off topic>

Once I have mastered these pesky frames I will want to talk about DragAndDrop! Are you ready? Wink

brianE



I hope this helps:

#include <CtrlLib/CtrlLib.h>

// Refer to "Browse topics - src - CtrlCore - Ctrl" to see how positioning works

// initial window width
const int window_width = 600;
// initial window heighth
const int window_height = 400;

// fixed height of top rectangle
const int fixed_top = 100;
// fixed width of left rectangle
const int fixed_left = 50;

class App : public TopWindow
{
private:
	StaticRect top_left_to_right;
	StaticRect bottom_left;
	StaticRect bottom_right;
	
public:
	App()
	{
		// create StaticRect "top_left_to_right" with variable width and fixed height
		// set up variable width from left to right edge of window
		top_left_to_right.HSizePos(); // same as HSizePos(0, 0)
		// set up fixed height from top edge of window
		top_left_to_right.TopPos(0, fixed_top);
		// add color to make rectangle distinguishable
		top_left_to_right.Color(Red);
		// add rectangle to window
		Add(top_left_to_right);
		
		// create StaticRect "bottom_left" with fixed width and variable height
		// set up fixed width from left edge of window with fixed size
		bottom_left.HSizePos(0, fixed_left);
		// set up variable height from bottom edge of top_left_to_right to bottom edge of window
		bottom_left.VSizePos(fixed_top); // same as VSizePos(fixed_top, 0)
		// add color to make rectangle distinguishable
		bottom_left.Color(Green);
		// add rectangle to window
		Add(bottom_left);

		// create StaticRect "bottom_right" with variable width and variable height
		// set up variable width from left edge of bottom_left to right edge of window
		bottom_right.HSizePos(fixed_left); // same as HSizePos(fixed_left, 0)
		// set up fixed height from bottom edge of top_left_to_right to bottom edge of window
		bottom_right.VSizePos(fixed_top); // same as VSizePos(fixed_top, 0)
		// add color to make rectangle distinguishable
		bottom_right.Color(Blue);
		// add rectangle to window
		Add(bottom_right);
	}
};

GUI_APP_MAIN
{
    // window smaller than the fixed sizes seems not reasonable
    Size min_size;
    // double minimal width - otherwise resizing conflicts with fixed width (try out!)
    min_size.cx = fixed_left * 2;
    // minimal height
    min_size.cy = fixed_top;
    
    App app;
    app.Title("Resize window to see what happens");

    // window size: left edge, top edge, width, height - 0, 0, ..., ... means "center window"
    app.SetRect(0, 0, window_width, window_height);
    app.SetMinSize(min_size);
    app.Sizeable();
    app.Run();
}


... and don't look for frames - you won't find any Razz !

Werner
Re: Understanding Frames [message #3857 is a reply to message #3856] Sat, 01 July 2006 23:11 Go to previous messageGo to next message
fudadmin is currently offline  fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania
Ultimate Contributor
Administrator
Werner wrote on Sat, 01 July 2006 21:34


...
I hope this helps:
...



understanding frames? Wink
Re: Understanding Frames [message #3858 is a reply to message #3851] Sun, 02 July 2006 01:06 Go to previous messageGo to next message
brianE is currently offline  brianE
Messages: 13
Registered: June 2006
Promising Member
Thank you, Werner. Sorry for the delay in replying but I have been trying all day to pull apart things like the ToolBar to see how this FrameCtrl/CtrlFrame stuff works. Sadly ATM it is a bit too deep for me as I cannot decide which bits are vital and which bits are helpers.

Your code was so well commented that it was all obvious what to do and not only did it work (you knew that!) but I was able to Add a Splitter to one of the StaticRects and it did what it should - hoorah!

I guess that this is how I must solve my problem at the moment but I am left with the feeling that something is missing - as you said, no Frames. Maybe when I understand Upp more generally I will come back to this.

BrianE
Re: Understanding Frames [message #3859 is a reply to message #3858] Sun, 02 July 2006 11:18 Go to previous messageGo to next message
forlano is currently offline  forlano
Messages: 1202
Registered: March 2006
Location: Italy
Senior Contributor
I've translated the Werner's example in the designer language. Below is the result. StaticRect can be colored. Instead LabelBox seems cannot be colored... at least not directly... maybe there is an indirect way... again via Display?... Rolling Eyes

Luigi

#include <CtrlLib/CtrlLib.h>

#define LAYOUTFILE <staticrect/layout.lay>
#include <CtrlCore/lay.h>

class App : public WithFramesLayout<TopWindow> {
public:

	typedef App CLASSNAME;

	App();
};

App::App()
{
	CtrlLayout(*this, "Resize window to see what happens");
	top_left_to_right.Color(Red);
	bottom_left.Color(Green);
	bottom_right.Color(Blue);
	this -> Sizeable();
}

GUI_APP_MAIN
{
    App app;
    app.Run();
}


////////////// layout.lay ////////////////
LAYOUT(FramesLayout, 605, 451)
ITEM(StaticRect, bottom_right, RightPosZ(13, 466).BottomPosZ(8, 377))
ITEM(StaticRect, bottom_left, HSizePosZ(9, 478).BottomPosZ(8, 377))
ITEM(StaticRect, top_left_to_right, HSizePosZ(9, 13).VSizePosZ(8, 384))
END_LAYOUT

Re: Understanding Frames [message #3860 is a reply to message #3859] Sun, 02 July 2006 13:13 Go to previous messageGo to next message
Werner is currently offline  Werner
Messages: 234
Registered: May 2006
Location: Cologne / Germany
Experienced Member
forlano wrote on Sun, 02 July 2006 11:18

I've translated the Werner's example in the designer language. Below is the result. StaticRect can be colored. Instead LabelBox seems cannot be colored... at least not directly... maybe there is an indirect way... again via Display?... Rolling Eyes

Luigi

#include <CtrlLib/CtrlLib.h>

#define LAYOUTFILE <staticrect/layout.lay>
#include <CtrlCore/lay.h>

class App : public WithFramesLayout<TopWindow> {
public:

	typedef App CLASSNAME;

	App();
};

App::App()
{
	CtrlLayout(*this, "Resize window to see what happens");
	top_left_to_right.Color(Red);
	bottom_left.Color(Green);
	bottom_right.Color(Blue);
	this -> Sizeable();
}

GUI_APP_MAIN
{
    App app;
    app.Run();
}


////////////// layout.lay ////////////////
LAYOUT(FramesLayout, 605, 451)
ITEM(StaticRect, bottom_right, RightPosZ(13, 466).BottomPosZ(8, 377))
ITEM(StaticRect, bottom_left, HSizePosZ(9, 478).BottomPosZ(8, 377))
ITEM(StaticRect, top_left_to_right, HSizePosZ(9, 13).VSizePosZ(8, 384))
END_LAYOUT




Much better than my example code:

- The window doesn't flicker when being resized.
- No "resizing-to-minimum-problem".

Unfortunately I haven't been able so far to find out what makes the difference. It seems to be buried in the internal handling of CtrlLayout.

Werner
Re: Understanding Frames [message #3861 is a reply to message #3857] Sun, 02 July 2006 13:53 Go to previous messageGo to next message
Werner is currently offline  Werner
Messages: 234
Registered: May 2006
Location: Cologne / Germany
Experienced Member
fudadmin wrote on Sat, 01 July 2006 23:11

Werner wrote on Sat, 01 July 2006 21:34


...
I hope this helps:
...



understanding frames? Wink


Actually yes! Rolling Eyes

1.
Understanding frames includes to know when not to use them. Very Happy

2.
The first post to which I replied brought up a specific problem. The writer only assumed that frames would be required. Smile

Werner

P. S.:
You can ask me when you feel framed by real framing problems. Very Happy But be warned. I'm just a hobby programmer and a newbie to Ultimate++, too. Rolling Eyes

W.

P. P. S.
Sorry about the "framing" pun. But on the one hand it's difficult for a non-native speaker to create good puns. On the other hand it's really tempting. Embarassed

W.
Re: Understanding Frames [message #3862 is a reply to message #3860] Sun, 02 July 2006 14:08 Go to previous messageGo to next message
brianE is currently offline  brianE
Messages: 13
Registered: June 2006
Promising Member
Slowly I am getting there! The Layout version works well: drop a StaticRect on layout; do Ctrl-T to get text; adjust the VSizePos etc; Ctrl-T to get back to layout; things happen!

I notice that you can add '.Color(Red)' to the text but that it isn't reflected in the layout - that would be handy.

I also notice that if I put a button in a StaticRect it isn't 'owned' by the SR but still belongs to the layout as a whole. I realise that you can have a separate layout for each SR and drop buttons on to that, though.

I just thought of something: If you were to use Splitters to cut up the main window AND a Splitter could have one (or more) sections of fixed size (height or width, depending), then Splitters would be all I needed! Is this possible?

(I still want to understand frames, though, he said, sotto voce)

brianE
Re: Understanding Frames [message #3863 is a reply to message #3861] Sun, 02 July 2006 14:45 Go to previous messageGo to next message
brianE is currently offline  brianE
Messages: 13
Registered: June 2006
Promising Member
Werner wrote on Sun, 02 July 2006 12:53

1.
Understanding frames includes to know when not to use them. Very Happy

2.
The first post to which I replied brought up a specific problem. The writer only assumed that frames would be required. Smile

Werner



Both good points, Werner, so thank you for that. It is easy to make assumptions about things you know little of and I am guilty! So long as people are kind in the way they write to us new folk then all advice is welcome. I was once part of a newsgroup and made an error - I was severely shouted at by a guru and never went back.

brianE
Re: Understanding Frames [message #3917 is a reply to message #3863] Sun, 09 July 2006 15:53 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14112
Registered: November 2005
Ultimate Member
OK, here is a simple way how to undestand frames:

Frames emerged to solve the simple problem: You have some widget that has scroll-bar(s). Now the question is how to organize all things.

Without frames, you would need to use some sort of composition: One "parent" Ctrl, which would provide some sort of static edge, scroll-bar widget and "view" widget.

Unfortunate thing about this arrangement is that "view" widget becomes "contained" inside parent Ctrl, but in dialog you need to work with parent Ctrl. So it is e.g. difficult to create subclass of such view.

Solution: scroll-bar is "frame". You can freely add frames to Ctrl and the important thing about them is that they "reduce" the view area. With this concept, you can even make that static edge a frame. Moreover, you can alter existing widgets by adding further frames (e.g., you can add HeaderCtrl to LineEdit etc...)

There are things to remember

- frames do not have to be widgets, but can be. E.g. ScrollBar is derived both from Ctrl and Frame. Means you can add it to widget either as regular child, or using AddFrame.

- CtrlFrame interface is designed in a way that makes possible to use single static frame instance for multiple widget.

Mirek
Re: Understanding Frames [message #3918 is a reply to message #3851] Sun, 09 July 2006 15:58 Go to previous message
mirek is currently offline  mirek
Messages: 14112
Registered: November 2005
Ultimate Member
OK, now to reply to OP question:

Yes, you can have other widgets inside the frame. There are several different ways how to achieve that; perhaps the most simple is to use StaticRect-based frame and put things inside it.

Something like


FrameLeft<StaticRect> myframe;
Button b;
.....
mywidget.AddFrame(myframe);
myframe.Add(b.HSizePos().TopPos(0, 10));
.....


Mirek
Previous Topic: Mapping button to CALLBACK
Next Topic: scrolling without Frame and wrapping Ctrl?
Goto Forum:
  


Current Time: Sun Nov 10 20:20:03 CET 2024

Total time taken to generate the page: 0.01111 seconds