I have created a custom dijit widget which contains a grid and some buttons.
What is the right way to destroy it? override uninitialize, destroy, destroyRecursive? which method and in which order?
Thanks.
Generally uninitialize is the best place to do this, since it is an extension point called within the destroy function before other teardown occurs.
That said, depending on how you are adding your child widgets, you may not actually have to do anything. For instance, if you are defining your child widgets within a template, widgets declared within a template automatically get added to an array which is iterated through in destroy.
If you wanted to be sure, for testing you could connect to the destroy methods of your child widgets to log a message when they get called.
Related
I am trying to come up with an efficient way to organize clickable menus for the objects in my game. I made a Menu class, from which all possible menus inherit:
class_name Menu extends Control
#contains functions (for buttons) that all menus have in common
func open_menu():
pass
func close_menu():
pass
To make a menu specific to buildings, I inherit all functionalities from the Menu class:
class_name BuildingMenu extends Menu
# contains functions specific to all buildings
func upgrade_building():
pass
func delete_building():
pass
# ... many more ...
Now here's the problem: My HQ is literally just another building with a few extras and the main difference that it can't be deleted, so I'm thinking of inheriting from BuildingMenu. Is there a way to disable the inherited delete_building() function in the HQMenu script?
class_name HQMenu extends BuildingMenu
func delete_building():
# overwriting inherited function like this does not work...
# ... some HQ specific stuff here ...
I could just inherit from Menu and then copy paste everything from BuildingMenu except the delete_building() method, but this seems somewhat clumsy because now I have to edit two files if I want to change/add any building functions.
What is the correct way to do this?
SOLUTION:
Thanks to the suggestion by Thearot I've decided to move the delete_building() function into a new class from which all the regular (non HQ) buildings inherit:
Now here's the problem: My HQ is literally just another building with a few extras and the main difference that it can't be deleted, so I'm thinking of inheriting from BuildingMenu. Is there a way to disable the inherited delete_building() function in the HQMenu script?
This sounds like a violation of Liskov Substitution Principle. From a purely object oriented point of view, it would be preferible to make another class for a subset of buildings with what they have in common, than to have one building inherit from another if it has to disable some methods.
If your base class for all buildings implies that some buildings have to disable some methods, then it does not really have the methods common for all building, it has some extra ones.
To be clear, here I'm suggesting to add another extra intermediary class, and that way you don't have to delete nor duplicate methods.
If that is not an option for you… Congratulations! you have made a mess system complex enough that some kind of component based system begins to make sense. But don't jump the line, don't fret, it is OK.
If I understand correctly you have some contextual menus that show different options depending on what is selected or what you click on, right?
That means that the options are variable. Thus, use a variable. Add an Array field that has the names of the methods that should be linked to the menu. Then have the menu system discover the options by reading that Array, and connecting to functions with the names specified there.
And how you do add or remove options? You add them or remove them form the Array. Simple. You can populate the Array in _init.
To be clear, you can check if an object has a method with has_method. You call a method by name with call, or - of course - you could connect signals to them with connect (if prefer to populate an static menu for the object instead of having a dynamic one). Yes, I'm suggesting late binding.
Suppose I have a setting in NSuserdefaults that should affect a property for a lot (but not all) UIView objects, for example the font size.
The setting can also be changed from a 'main' viewcontroller and should be 'distributed' to UILabel objects that live in a UIView in a UITableviewcell inside a UITableView inside a UINavigationController inside a UISplitviewController and so on...
If I create this property on all levels of the controller and view hierarchy, and set the property when the property in the parent is set, this costs a lot of code.
Apple seems to prefer this pattern to manage the managedObjectContext by handing it to the child controller along the chain.
But this seems like overkill. Lot of code is just for passing around the value of the property, while nothing is done with it. I do however use this pattern to set properties in all subviews of a view at once (by recursively walking through all subviews).
Delegation seems to be just as bad, except maybe not if the delegate would be top level parent view controller. But then I would be passing the delegate around to all child view controllers.
Should I go with Notifications instead? I already have a controller listening to (all) changes in the NSUserDefaults via the NSUserDefaultsDidChangeNotification. Should that controller post a specific notification when my setting is changed? In that case, who should listen to it? Should it be the view controller that is responsible for the views involved?
After some more reading, I found advise in the book Cocoa Design Patterns from Buck / Yacktman, as they state:
As a general rule, use notifications when there are potentially many objects that may observe the notification. Use delegates when exactly one object is given an opportunity to influence or react to changes as they are happening.
So notifications is the answer.
I have my own custom component. This component extends from a basic container. I want to be able to access the itemRenderer instances that are being visualized. I know that the component mx:list has an internal getter that provides an array of Arrays containing the itemRenderer instances that render each data provider item. I want the same thing. Any idea how of how to do that?
To be more specific: I am setting the selected property of my dataProvider items to true or false. From the updateDisplayList funcion of my ItemRenderer I check for changes of the property and correct the border color of the selected ones. Unfortunately I have to force the updateDisplayList function. I already did this once on a ItemRenderer from a list. Only with the list it was practical because by making my own list I was able to get the list of items being rendered and therefore visualized (cannot be many). It was no overhead to go trough the rendered Items and updateDisplayList. But in this case I can have 100 items. Imagine checking and changing styles on so many items. Thanks
The Flex architects intentionally made this difficult to do, because they are properly encapsulating the component. In short, to even try to do this is a violation of good OOP principles.
That said, about 90% of the things you are probably trying to do can be done by manipulating the data item, and the remaining 10% can be done by using a ClassFactory for your itemRenderer that sets a custom property on your itemRenderer to a callback where you can look at the data available to the containing context and provide back a value based on that.
If you elaborate a bit more on your end goal, I can give you more specifics.
Edit in light of clarification:
You need to make your data object class dispatch an event when it changes (one way is to make it bindable, or just make the selected property bindable). Then, in your renderer, listen for the change event and take the appropriate action.
A second way to handle this would just be to refresh() the collection, storing the selectedItem first (if you care about that) and resetting it once the refresh has finished.
I believe you can access the itemRenderer instances through getChildAt method. Flex 3's container overrides "getChildAt", "numChildren", given that some children are logical children, while some are decorative children such as background, border and scrollbars.
Keep in mind that itemRenderer may not right away become available upon dataProvider assignment, as they may be created during the next component lifecycle. Check with the underlying container's documentation and find out which event to be listened when the renderers are surely created, so you can reliably access them.
Having read many tutorials, articles and questions, I am still have confusions about updating the GUI. Plus there are numerous related questions here on this website and still no luck - even though I think my problem is very simple.
Basically, I have a JFrame that has a JLayeredPane as its root container. And I have some layers of JPanels inside it.
The main issue is with updating a particular JPanel in this JLayeredPane. And for this particular Panel, I have implemented an update method that changes the contents inside it.
updatePanel(int para)
//doesn't remove this panel
//removes some existing labels and replaces it with new ones
Once I create the whole Frame, obviously just calling this method won't show any change displayed the frame.
private void static main (String[] args){
WindowFrame frame = new WindowFrame()//WindowFrame extends JFrame
frame.updatePanel(2);
.....
.....
}
And that's where I am stuck. I want to update the contents as the frame is displayed.
I saw these methods mentioned by people but due to nature of problems, I couldn't fully grasped the concepts. Plus the documentation on these methods isn't really helping - at least to me.
revalidate()
validate()
repaint()
How/when should these methods should be called? Or is this not the right way of what I should be doing, given these methods and the problem I am trying to solve?
Thank you for your time.
Basically you need two methods:
revalidate()
This method does the same as invalidate() but in AWT event dispatching thread (i will just call it Swing thread later on)). It updates container and all of its ancestors (parent containers in which this one is placed) layouting.
Basically if you either move something inside this container or place/remove components inside of it you should call this method (or invalidate in case you are performing it in Swing thread, for example inside any Mouse/Action listener body or just inside).
repaint()
This method forces component, all its sub-components (if it has them) and parent container (basically if this component is NOT opaque) to update what they are "painting".
Usually you don't need this method since all standard Swing components know when to repaint themselves and they do it on their own (that ofcourse depends on components UIs and some other things). This method might be useful in case you have your own specific components with some unique painting-way (for e.g. some custom selection over the components) and in some rare problematic cases with standard components.
Also the way this method acts depends on the components placement (due to some Swing painting optimizations) - if you have some massive repaints rolling you'd better optimize them to repaint only those parts (rects) that you actually need to repaint. For example if you change the component bounds inside any container the best choice is either to repaint its old bounds rect and new bounds rect OR repaint rect that contains both of those bounds, but not the whole container to avoid repainting uninvolved in the action components.
So, basically in your case after some changes with panels you should call revalidate on their container (or invalidate) followed by repaint (in case revalidate leaves some visual artefacts) again for the container.
Guess i didn't miss anything and i hope that now you know the basic meaning of those methods.
revalidate at the end of your update method like so .
updatePanel(int para){
.....
.....
this.revalidate(); //of course this refer to the panel
parent.revalidate(); // parent refer to the window
}
How can I use an IComponentActivator instance for a component, not just specifying a type.
That is, instead of
Component.For<XYZ>.Activator<MyComponentActivator>();
I want to be able say
Component.For<XYZ>.Activator(new MyComponentActivator(someImportantRuntimeInfo));
Also, is there a way I can choose an activator dynamically for a non specifically registered component? That is, I want to have an activator that looks at the type being resolved, decides if it can activate it, and if not, responsibility for activation should be passed on to the default activator.
So basically I want a global IComponentActivator that has the following logic:
Create(Type type){
if (ShouldActivate(type)){
DoActivate(type);
}
else{
// do default activation here somehow
}
}
Thanks!
EDIT
Just use ILazyComponentLoader
Activators are instantiated by the container, and there is no way to provide instances OOTB.
If you really want to do this, I'd say you can extend the container itself.
Put your custom instace activators in ExtendedProperties of your component under a well-known key
inherit from DefaultKernel
Override CreateComponentActivator method
In there return the activator from ExtendedProperties of the component
There's no way to create global activator. You can add IContributeComponentModelCreation implementation that switches the activator to some custom one wen creating your component if you really want to.
But the most important question is this:
What are you trying to achieve by
this? Why do you want to do this in
the first place?