I need to stop rearrangement of static methods in my classes on Ctrl + Alt + L. Namely, all static methods are grouped at the top of a class when I apply code reformatting.
Help me to find and switch off this option from PhpStorm settings. I'm really bored with it.
These are my Arrangement tab settings:
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.
I want to make a tab on the top of screen like this :
I know that tabLayout and viewPager can solve it on the phone. However, how to do on the android tv?
There are several ways you could do this - but I think the short answer is no matter what you do, it'll have to be custom. So far leanback is the only framework offered by Google for any TV specific components and that framework only provides you with a left navigational drawer.
I can offer one solution for if you're using leanback. You could use a BrowseFragment with a custom TitleView which has tabs and keeps track of the focus of the tabs within. As long as your custom view implements TitleViewAdapter.Provider then you can use it with a BrowseFragment as the TitleView. The benefit to this is that you can have it automatically animate in and out from the top with little additional work.
As for the custom view, you can specify focusRight and focusLeft on each tab and have an listener onFocus or onClick to swap out the fragments in the BrowseFragment. This class in leanback shows how to swap fragments in the BrowseFragment (specifically PageRowFragmentFactory).
I would highly recommend you clone the leanback showcase app that the Android team put together and play around in that.
For the specifics of customizing the TitleView, it'll look something like the below:
Create your custom view
class YourTitleView extends RelativeLayout implements TitleViewAdapter.Provider {
... do custom view setup/logic here ...
}
Create an XML file named lb_browse_title.xml. This overrides leanback's layout which they use to create their TitleView.
Put your title view in this lb_browse_title.xml file and ensure it has the id of #+id/browse_title_group. This is so leanback knows to grab your title view.
<com.your.android.app.views.YourTitleView
xmlns:android="http://schemas.android.com/apk/res/android"
android:id="#+id/browse_title_group"
android:layout_width="match_parent"
android:layout_height="wrap_content"
style="?attr/browseTitleViewStyle" />
Then create a Fragment that extends BrowseFragment and it should apply your title view automatically. Please refer to the leanback-showcase app for how to get a BrowseFragment up and running.
I have a menu with five buttons. Menu is visible all the time. there is click event for each menu item. which slides corresponding movie clip from left to right. each movie clip has different nature events and respective animation and activity. for example tab 1 brings the video page. and within that movie clip I have video events like play pause volume and on complete etc. events and code. tab 2 has button group for Time and another button group Features. depending on user selection code will calculate and show value on a animated counter. tab 3 has button group for Time and button group Source. as per the user selection it will calculate and show the values as animated graph. and so on.
Right now I have all the individual tab movie clip has its own time line code for its own events. and some crossover variables and references with other tabs. Everything is working as expected. No problem. I know time line code is not the best way to do any complex project.
So, I would like to get the entire coding as one class or more classes if that is the correct way.
I am beginner as far as class logic. I have already created Main as document class and could control the general navigation of tabs and their initial look. But stuck at tab specific button events and other such unique events for the specific tab.
Any help is greatly appreciated. Thanks in advance.
any similar example or suggestions.
First of all, thanks a lot for a prompt response. It seems like I am not even a beginner. I need to read a lot and probalbly grasp all fundamental concepts thoroughly. I have gone through both the links suggested in your comments. I am trying to digest the stuff slowly. I do not have any formal informal education regarding OOP or any sort of programming. To be honest, I have hard time understanding the code you have suggeted. Not because of your code but because of my level of caliber. I will have to spend some time to make myself clearer regarding events and sequence etc. different tab contents are as movieclips to main timeline and already placed on stage. It comes and goes to its corresponding tab button click event. I am not marking your answer as yes because I still need to my own homework based on your suggestion. Thanks a lot once again. I am sure I will ask few more questions later.
This is how I would design it:
I'd have a Menu Class, which only contains the buttons and "converts" clicks on them into more specific events. That might look something like this:
public Class Menu extends Sprite {
protected var buttons:Vector. = new Vector.();
public function Menu() {
super();
var loops:int = numChildren;
for (var i:int=0; i<loops; i++) {
var button:SimpleButton = getChildAt(i) as SimpleButton;
if (button) {
buttons[buttons.length] = button;
button.addEventListener(MouseEvent.CLICK, broadcastMenuEvent);
}
}
}
public function broadcastMenuEvent(e:Event):void {
var button:DisplayObject = e.currentTarget as DisplayObject;
dispatchEvent(new Event(button.name, true));//bubbling, can catch at any level
}
}
The way this is built, you can change the events that are being dispatched simply by changing the name you give the instance of the button on stage. Note that you need to apply Menu as the Base Class and not the Class for this to work if you have "declare instances automatically" unchecked, because doing it that way allows the compiler to generate those instance names for you in a way your base Class doesn't have to know about.
At this point, you can then deal with those events in another place--whether it's your main document Class or whether you have a separate Controller.
I would define each of the Views you described as a separate Class as well. If you have objects coming and going on the stage, you can use one of the techniques described here to handle that. Otherwise, it's fairly straightforward to address your timeline instances from the base Class instead of timeline code. Again, you can listen for those events in the main document Class or a dedicated Controller--the main point is to make sure your Views are not making any important decisions and usually they should not be editing data.
You can choose to have your Main Document orchestrate how the tabs get added and removed (I'm a big fan of using the timeline with goToAndStop, but not everyone shares this preference), or, again, you can separate this logic out to a dedicated Controller. I would suggest that if it's possible to generalize how your Views work to have them implement a single Interface. That way, you can give them a single instance name and manage them all with the same getter/setter pair (assuming you go the timeline route).
Note the Flash compiler isn't terribly sophisticated in this regard, so if you do this and your Views extend different parent Classes, you'll get compiler warnings. Just ignore these--they don't mean anything.
The thing you shoud try to root out of your code completely is the part where Views are referencing each other. The only time it's acceptable for one View to know about another is when it's a parent knowing about its child. Even then, try to have as little specific knowledge as possible. Notice in the Menu View I wrote as an example, the parent only knows there may be some SimpleButtons, but it has no specific knowledge of where they are on stage, what, specifically, is in them, or even what there instance names are.
Instead of having your Views know about one another, have a third party (which, again, you can choose to use the main Document Class for or not) that transfers requests for state changes (in the form of events) from one to another.
How would someone go about coding a 'window'? I'm starting to make a GUI, and I want to learn how to code one. One that can be skinnable, and one that actually loops and creates itself at runtime. I understand that this might be a bit vague, so I'll add details.
One that actually 'creates' itself. Most GUI tutorials I've looked on depends on an 'image' that just gets added on the screen. I want to be able to use skins in my windows. One where my 'skin' is just a collection of 'borders'. Then when I insert window.create(50,50) where 50,50 is my height, width, It would just create that window, following the skin.
I understand that it probably follows just like when a language draws a rectangle, it just follows a different set of rules (maybe?). However, for all my Google-fu skills I cannot find a tutorial that teaches me this.
Please Help. I didn't include the language I used as you can see, because I believe I just need to know how to create one. Anyway though, I am using Actionscript 3. A tutorial would be just fine, or even A SINGLE CLASS THAT HAS THIS FUNCTIONALITY, I'll just study the code. Or if you know one, maybe a whole book about GUI and programming it :D
Pure As3.0 GUI coding is quite troublesome. I try to Googling, but not come out well. anyway for my case, i generate using a SWC, and Class Mapping and Customizing. but i'm not sure best way. in other way i use a bit101 library. this is gives me want Window, Charts, Componets easily of high abstraction. see the below image.
It can be pretty hard and complicated to do, or very easy, it just depends on how flexible your solution should be. You need firstly to design a structure of your program and approach to the problem.
I like to go from the image of how it should look like from API point of view. I think I would create a GUI element like this:
var wholeGui:MyGUI = new MyGUI();
var window:IGuiElement = new GuiWindow(dataObject, skinObject);
wholeGui.addElement(window);
So what would you need?
1) Object that would manage all GUI elements. Why? Simply because your GUI elements shouldn't be destroyed by themselves if user will click "X" on your little window. The wholeGui object would manage them and listen for any events including those that would destroy them. You may consider creating custom events for interaction between the wholeGui object and your window object if this interaction is going to be complicated.
2) Interface for your GUI objects. Some problem here is that AS3 actually doesn't have interface for Sprite, and you would like to interact with it like with extended Sprite. The workaround here is to have in this interface a declaration like this:
function asSprite():Sprite;
And your implementation in GuiWindow would look like this:
public function asSprite():Sprite {
return this;
}
And your GuiWindow class should extend Sprite of course. Then you would have access to it's Sprite properties and methods by writing for example: window.asSprite.startDrag();
This interface should give you abilities that you need to operate on your GUI element.
3) Class for your GUI element, in this example GuiWindow.
4) Class for your data that would be injected into your element. If you would load data dynamically, and from some location, you would need to deal with the situation when no data can be provided - but that logic would be inside your window.
5) Class for your skin - so you would be able to dynamically create a skin object and use it to create your window in a way you want.
That's just few thoughts to consider.
PS. It may be good idea to fill GuiWindow object with data AFTER creating it, and not in constructor, as you would be able to visualize loading process then.
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
}