trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: March 2012

Re: [trinity-devel] Tim - need a 'cheat sheet' to use to solve TQxzy not declared issues

From: Darrell Anderson <humanreadable@...>
Date: Sat, 24 Mar 2012 17:27:35 -0700 (PDT)
>   It would be nice to have a troubleshooting 'cheat
> sheet' to use to solve TQwhatever not declared failures when they are encountered.
> I can read c++, I know what constructors are, what destructors are, what
> public and private members are, etc.., but with a project the size of TDE, with
> the multiple levels of submodule inclusion through the git tree, my eyes glaze
> over trying to chase down where the declaration problems are when they are
> encountered.
> 
>   If I knew where to start, then I wouldn't mind trying
> to figure out where to fix the declaration error. But not knowing whether I just
> start grepping within tdeadmin for TQListViewItem or whether I need to start in
> tqtinterface or what, I'm somewhat left chasing my tail. I don't know if it is
> possible, but I know it would help me and others if there was something like:
> 
> TQString objects are type ......
> TQListViewItem objects are type .....
> 
> To fix TQxzy declaration issues:
> 
>   (1) grep for '___________' in ___________;
>   (2) if declare ___________ found then
>   (3) ___________; else
>   (4) then grep in ______________;
>   (5) if declare ____________ found then
>   ...........
> 
> 
>   Just some simple decision tree would go a long way to
> get everyone involved in helping with these issues and also provide a valuable tool
> that would help cut down bug squashing time even if the person can't solve it by
> being able to say 'I got to step 8 in troubleshooting and 1-7 are fine, but I
> can't figure out what to do next...'
> 
>   Worth a thought. If somebody else can help here, please jump in.

I have a copy of the original Qt3 docs. Sometimes I browse those docs to understand what is happening. I remove the T, t, or TQT_ prefix and the docs pretty much are the same.

Sometimes the problem is a missing header include. Often I grep the TQt headers for the particular function name. Then I look in the cpp to verify the respective header file is included.

Sometimes the trail is maddening because one TQt header includes another TQt header, which includes another TQt header. Ultimately there is an inclusion of the mother of all TQt headers, tqt.h. That is where my trail often ends because when the header is being included then there is some other explanation for the declaration error.

Then there are scope errors, as you alluded. Also class errors.

I get confused because the old code compiled fine without the TQt layer. Merely prefixing names should not cause problems. Yet things still break. Like you I don't know where to turn. I have spent hours and hours reading around the web trying to learn more. I do enjoy learning, but the cost is huge right now. I'm sure I have learned something along the journey, but most of the time I surrender. I can grasp only so much with my currently limited knowledge.

Darrell