U++ forum: Welcome to the forum

Search on this site

Search in forums

Home » U++ Library support » U++ Widgets - General questions or Mixed problems » static Ctrl causes running failure

Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend

static Ctrl causes running failure [message #24145]

Tue, 29 December 2009 07:33

bonami
Messages: 186
Registered: June 2007
Location: Beijing

Experienced Member

/* global, i.e, static */ Ctrl dl;

this causes program to fail in debugging mode under Ubuntu.
stack is,

Ctrl()
Ctrl::IsCompositedGui()
XAtom()
XAtomRaw()
XInternAtom(Xdisplay = 0, name = "_NET_WM_CM_S0", XFalse);

In my attachment, I used a more complexed case, which I found out to be unnecessary.
I can use other tricks other than static Ctrl, but why cannot I use this, since it conforms to grammar?

Attachment: test.zip
(Size: 1.08KB, Downloaded 283 times)

[Updated on: Tue, 29 December 2009 07:49]

Report message to a moderator

Re: static Ctrl causes running failure [message #24152 is a reply to message #24145]

Tue, 29 December 2009 14:19

mirek
Messages: 13975
Registered: November 2005

Ultimate Member

It is known feature:

http://www.ultimatepp.org/srcdoc$Core$Caveats$en-us.html

Implementation difficulities in CtrlCore (widget gets created before GUI is initialised).

There is trivial workaround for majority of cases:

MyGlobalWidgetType& MyGlobalWidget() {
static MyGlobalWidgetType x;
return x;
}

(then of course, call this after gui is running, but that is OK for most uses).

Mirek

Report message to a moderator

Re: static Ctrl causes running failure [message #31807 is a reply to message #24152]

Tue, 29 March 2011 11:23

kohait00
Messages: 939
Registered: July 2009
Location: Germany

Experienced Contributor

i was using a similar approach and switched to INITBLOCK / ONCELOCK since i thought they were about to be initialized *after* the GUI main init stuff. but this is not neccessarily the case right?
INITBLOCCK / ONCELOCK are part of Core..

having a stack object EditField i.e. in a INITBLOCK yields same error. the control is created first, then gui stuff. so it's not a problem of static controls, but of their early init.

is there a possib to securily trigger the GUI init stuff first?

the problem is also that, once the i.e. EditField has been inited somewhere before GUI, even if it ceases to exist, the effects of the wrong overall init sewuence are visible for later controls.

seems as if some global params of gui are beeing spoiled up.
interestingly enough, this happens in msc debug, not in optimal.

attached is a test case.
compile MSC9 GUI MT, debug

Attachment: StatTest.rar
(Size: 1.09KB, Downloaded 228 times)

Report message to a moderator

Re: static Ctrl causes running failure [message #32011 is a reply to message #31807]

Sat, 16 April 2011 21:28

mirek
Messages: 13975
Registered: November 2005

Ultimate Member

kohait00 wrote on Tue, 29 March 2011 05:23

is there a possib to securily trigger the GUI init stuff first?

No.

Mirek

Report message to a moderator

Re: static Ctrl causes running failure [message #32014 is a reply to message #32011]

Sun, 17 April 2011 14:07

kohait00
Messages: 939
Registered: July 2009
Location: Germany

Experienced Contributor

thanks, mirek. it was just out of curiosity..

there is no real reason to have a static control somewhere around. and it can be avoided in most cases. if not, it should be considered to rethink the model. so the current 'constraint' can remain.

Report message to a moderator

Previous Topic:	Show() in .usc
Next Topic:	BUG? DropList shows first of entries with same key

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Tue Apr 16 12:23:43 CEST 2024

Total time taken to generate the page: 0.01583 seconds