Is there in wxFrame such event, when frame fully painted, so I can query data while interface is done?
Now I quering some data in Application::OnInit() function right before return true and interface not painting while data is quering. Looks ugly.
Not sure what exactly are you trying to do here, but you might be interested in CallAfter()
Related
Is it possible to detect if something has changed in the view hierarchy without caching and comparing the whole view-hierarchy again and again ? Is there a global notification or something similar, that indicates that a view was removed or added to the current hierarchy?
Currently we are using a Timer that triggers a method which is responsible for detecting a specific UI-Element on screen. But this is way to expensive.
I know that there is method called willMoveToSuperView and that i could overwrite this in my UIView baseClass to trigger a event or something like this. However, i think this is not an elegant way of solving the Problem because it requires a lot of Refactoring for a "simple" task like this.
So my final Question is:
Is there an performant way of detecting changes in the view hierarchy ?
I am trying to figure out the purpose of what the .parent property achieves in this method and the "get[ClassNameHere]" methods in general that feature this property being called.
-(HudLayer*) getHud
{
return (HudLayer*)[self.parent.parent.parent getChildByTag:kTagHudLayer];
}
It's not possible to know the details from just this method shown here. But the .parent does return the Cocos parent, sprite or layer, to which the current cocos object belongs as a child. Essentially this code suggests you have a sprite or layer with a child that has more children and more children of those children, and this is a way to find out who the big parent up the stream is, and then get a new child from that parent.
Personally it seems pretty sloppy to me. I'd never code that way myself. Hard to read (as you can see) and having so many parent properties strung together like this is opening a lot of room for bugs. It would be wiser if the top parent did what it needs to do rather than a distant grandchild going up the chain; it breaks the MVC model a bit to do it as shown here.
Probably class HudLayer has a parent property that points to another object of the same kind, thus having a parent property pointing to another HudLayer and so on, climbing up for three levels. Then it just sends a getChildByTag message to it.
I'd like to add images next to my cells in my nsoutlineview.
I'm having a really tough time doing this. I'm coming from iPhone development, so I was thinking of making a custom cell to do this, but it seems like NSCell is a control, not a view.
I've looked at the SourceView sample code, but it's tremendously confusing. It seems like this should be a really simple task as it's such a common interface component.
I currently have a working nsoutlineview which only has text, and i've implemented the following delegate methods:
-outlineView:child:ofItem:
-outlineView:isItemExpandable:
-outlineView:numberOfChildrenOfItem:
-outlineView:objectValueForTableColumn:byItem:
-outlineView:setObjectValue:forTableColumn:byItem:
-outlineViewSelectionDidChange:
Check out PXSourceList. It does this (using custo drawing), so you can either just use it directly or rip the drawing code into your own app, etc.
Apple has an example on how to do this:
http://www.cocoadev.com/index.pl?NSTableViewImagesAndText
I've a fairly complex window that is backed by a controller class that is obviously growing to meet the needs of my view window. While I believe I am sticking to proper MVC I'm still having problems managing a fairly largish controller class.
How do you breakdown your objects? Maybe use Categories? For example, one category to handle the bottom part of the window, another category to handle my NSOutlineView, another category to handle a table, and so on and so forth?
Any ideas or suggestions are welcome.
It sounds like it's a complex window controller that's growing to unmanageable proportions? This is getting to be a more common issue because of applications which, like the iApps, do most of their work in a single window.
As of Leopard, the recommended way of breaking it down is to factor out each part of the window into its own NSViewController subclass. So, for example, you'd have a view controller for your outline view, and a view controller for each of your content views, etc.
Also, I'd like to second the use of #pragma marks to divide code files up into segments, and in addition to categories, I also like to use class extensions for private methods.
It's a simple answer, but the code folding feature of the Xcode IDE can be handy for focusing your attention on sections of a class. Another little thing that might help is going to View->Code Folding and turning on Focus Follows Selection. This makes it so the background color of the scope of your current selection is white while everything else is shades of gray.
Categories are ideal for this. Create a new file for each category, and group them by functionality, as you suggested.
I've tried using Categories in situations like this and I just end up confusing myself, wondering how in the world I'm calling that method when it's "obviously" not in the class I'm looking at.
I'd recommend liberal use of #pragma mark in your source code. Makes it super-easy to browse through all your methods.
I am confused about how to go adding objects (images,etc) into an app. I will keep my example very basic so I can get a grasp on this. Let's say I want simple objects in an app. Say they are the smilies like the ones that are available in this forum software. If you wanted to add a bunch (like 4 not 400) to a view, is it better to just add them with using a UIImage or should you create a "smilieGuy" class with the various smiley face images (happy, sad, mad) and a method to change their mood (image to reflect mood). From what I understand, with the class you could create a happy object, a sad object, etc in your view based off of the class and then at anytime you could say changeMood and change the image to whatever mood you wanted.
Is the class approach actually possible and is it a better approach?
The class approach is preferable.
It allows you to separate the interface ([userFace setHappy]) from the implementation (self.image = [UIImage imageNamed:#"Happy.png"]). You can then change the logic, or create further variations without having to change any of the other display code.
I would also suggest creating an Emoticon class as a subclass of UIImageView. Inside the class, you could load your multiple images and use them to set the image property of your superclass.
You might also want to check out the animation properties of UIImageView to achieve Skype style smilies.