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++ TheIDE » U++ TheIDE: Layout (Forms) Designer » Can't use mutators of custom widgets in Layout Designer
Can't use mutators of custom widgets in Layout Designer [message #13665] Sat, 19 January 2008 20:27 Go to next message
jlfranks is currently offline  jlfranks
Messages: 55
Registered: May 2007
Location: Houston, TX, USA
Member
We're developing a touch screen app that uses lots of custom widgets.

We have added Set and Get methods for custom members in the specialized widget. While we can see and set these in the Layout Designer, the compiler is not happy and complains.

It looks like if these properties are not in the Ctrl base class, we should not expose them to the Layout Designer.

We've removed them from the USC file and now set them in the constructor. Sure would be nice to see and set them in the Layout Editor.

Is there a way around this limitation?

--jlf
Re: Can't use mutators of custom widgets in Layout Designer [message #13975 is a reply to message #13665] Mon, 04 February 2008 15:41 Go to previous message
mirek is currently offline  mirek
Messages: 11715
Registered: November 2005
Ultimate Member
jlfranks wrote on Sat, 19 January 2008 14:27

We're developing a touch screen app that uses lots of custom widgets.

We have added Set and Get methods for custom members in the specialized widget. While we can see and set these in the Layout Designer, the compiler is not happy and complains.

It looks like if these properties are not in the Ctrl base class, we should not expose them to the Layout Designer.

We've removed them from the USC file and now set them in the constructor. Sure would be nice to see and set them in the Layout Editor.

Is there a way around this limitation?

--jlf



Yes. The problem is ordering. E.g. LeftPos returns Ctrl&, so you cannot bind derived class method on this in the chain.

Means, the most derived methods must be .lay stored first. Sometimes this happens naturally, if not, you can use "ordering operator" @. See e.g.:

ctrl Label {
	group "Static";

	GetMinSize() { return XMinSize(); }
	GetStdSize() { sz = GetTextSize("Label", .StdFont); sz.cy += 6; return sz; }

	>TextCtrl;

	Doc    SetLabel ? "Label of control" ;
	Align  SetAlign = ALIGN_LEFT @2;
	Font   SetFont = StdFont() @2;
	Color  SetInk = :SBlack @2;
	Frame  SetFrame @3;



Here @2 or @3 "pushes" SetFrame or SetAlign "up" to base class, means they will be before SetLabel in .lay.

More specifically, the level for each attribute is the depth of bases introduced by ">" (here >TextCtrl). Means for Label, attributes in TextCtrl will have level 1 for Label, unless they are too altered by @. Each defined attribute starts at 0, but adds @.

Uff, I do not see a better way how to explain this Wink

Mirek
Previous Topic: Looking for a Panel Ctrl...
Next Topic: Problem with tutorial
Goto Forum:
  


Current Time: Sat Feb 23 19:57:10 CET 2019

Total time taken to generate the page: 0.00709 seconds