On Sep 20, 2008, at 10:47 PM, naresh k wrote:
>>> ScreenLogin::ScreenLogin(sClassName): Screen(sClassName)
>>> Log->Trace("In constructor");
>>> // do something
>> *A few (brief) points.
>> 1. That's not valid C++
>> 2. Screen might not be the best base class as another class may
>> already implement some of the functionality you want.*
> *1. I am not sure what's wrong with the C++ notion in my above
You're defining the the ScreenLogin ctor but your argument list is
invalid. It's obvious to me that sClassName is a formal parameter name
but you've given it no type. The compiler is going to treat that as a
type sClassName with no formal parameter name. So it'll either die
because of that or because sClassName is not a valid type, not sure
which error will cause the diagnostic first.
> 2. I chose Screen as my base class simply because my to-be-
> (ScreenLogin) is to be inserted between ScreenSelectStyle and
> ScreenDifficulty. Though my required features are close to
> i can't use that as my base class as ScreenNameEntry expects the
> game to be
> played to fill its vectors. My screen comes even before the game is
Maybe that really is the best choice, I'm not sure. Other screens
provide more functionality by default, but maybe that isn't needed.
>> *3. You need to use REGISTER_SCREEN_CLASS(**ScreenLogin) to
>> register you
>> 4. The Class=Foo means to instantiate the class registered as Foo. In
>> this case, ScreenAttract.
> *3. This is enlightening but sorry to say i didn't find any
> method to
> register the screen classes in StepMania. No such Macro also exists.
> curious now if every screen class is really registered internally in
> StepMania . and how to we do a screen class registration?
I'm not sure where you were looking, but that macro is defined on line
20 of Screen.h which contains the comment:
// Each Screen class should have a REGISTER_SCREEN_CLASS in its CPP
Furthermore, it is most definitely used.
$ grep REGISTER_SCREEN_CLASS Screen*.cpp|wc -l
> 4. Yes exactly. Nearly every screen with some functionality has been
> without using Class=Foo but i am not able to do the same for my
> The application simply hangs when it is expected to show on screen.
> and if i
> use Class=ScreenAttract, the routing doesn't get back to my class
> constructor !! ScreenAttract gets instantiated and later calls its own
> destructor by my class constructor is simply not invoked.
If there is a Fallback="Bar", then the metrics for Bar are loaded as
well. This happens recursively with later stuff overriding earlier
stuff. The latest Class="Foo" in the fallback chain is what gets
> I have observed that ScreenRanking works in the same fashion, where
> ScreenAttract is instantiated but later is routed to ScreenRanking's
> constructor. *
ScreenRanking uses the class ScreenRankingLines which is a subclass of
ScreenRanking which is a subclass of ScreenAttract. So what happens is
ScreenRankingLines is instantiated and all of the superclass ctors are
invoked in order which eventually includes ScreenAttract and then
ScreenRanking and then finally ScreenRankingLines. There's nothing
being "routed" anywhere.
> Why doesn't it happen to my class?
I really have no idea what you expect to happen. You told it to used
ScreenAttract so it happily instantiated ScreenAttract. You have to
tell it to use your class and to be able to do that, you have to
register you class.
>>> *5,6. ScreenAttract is instantiated in the information screens
>>> such as for
> ScreenCompany , ScreenCredits and i thought same goes for
> ScreenCaution. But
> in a Literary sense what you said seems logical. *
I think part of the confusion here is that there are three namespaces
for screen names. There is the c++ class name, there is the name
registered for a given screen, and there is the name of the screen
used in the metrics. I believe that the first two are always the same,
although there is nothing preventing a screen class from registering
itself under a different name.
ScreenCompany isn't a c++ class name or even a registered name. It is
something that exists only in the default theme metrics. The class
actually used is the class which is registered as "ScreenAttract"
which is, of course, the c++ class ScreenAttract.
ScreenCaution is also not a c++ class name or a registered name. It
also exists only in the metrics. It falls back on
ScreenSelectMasterBlank which uses the class ScreenSelectMaster. Thus
ScreenCaution is instantiated as a ScreenSelectMaster.
> This is interesting. I have made use of the following two statements
> which i
> guess are solely responsible for creation , loading of a new screen.
> m_pBackground.LoadFromAniDir(....); //i have the apt BGanimation
> layer for
> my //screen in BGanimations folder.
> X.AddChild(&m_pBackground); //Pardon me for using X ..
> Now if i make use of the above callers in my screen constructor that
> i guess
> should do. Am i missing something here? Is there more to show a
> screen? *
You should probably be using ScreenWithMenuElements as the base class.
That will load appropriately named underlay and overlay. You should
look at examples of other screens which use ScreenWithMenuElements and
copy one of them.
"Anyone who says that the solution is to educate the users
hasn't ever met an actual user." -- Bruce Schneier