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 » static Ctrl causes running failure
icon9.gif  static Ctrl causes running failure [message #24145] Tue, 29 December 2009 07:33 Go to next message
bonami is currently offline  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 137 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 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 11701
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
Re: static Ctrl causes running failure [message #31807 is a reply to message #24152] Tue, 29 March 2011 11:23 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 933
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 99 times)
Re: static Ctrl causes running failure [message #32011 is a reply to message #31807] Sat, 16 April 2011 21:28 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 11701
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
Re: static Ctrl causes running failure [message #32014 is a reply to message #32011] Sun, 17 April 2011 14:07 Go to previous message
kohait00 is currently offline  kohait00
Messages: 933
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.
Previous Topic: Show() in .usc
Next Topic: BUG? DropList shows first of entries with same key
Goto Forum:
  


Current Time: Tue Feb 19 10:28:20 CET 2019

Total time taken to generate the page: 0.00583 seconds