My game takes around a minute to load in android till the first screen appears. Till the time its loading, jmonkey’s input manager seems to queue all inputs which results in nasty behavior(automatic button clicks) as soon as my first nifty screen loads.
Same happens when the scene loads(which again takes a while on pressing the appropriate nifty button). This happens despite the fact that I set mappings and listeners in the last App State which loads.
Is there a way to flush all previous input which I can call just before and after adding listeners to input manager?
I dont do much work in update() and initialize of my appstates but some functions (reinitialize()) which I call on nifty's OnClick(), loads all the scene and models in the scene garph so it takes a while. Here is a pseudo code of my application
In Main.java {
// Nothing in SimpleUpdate()
// This app state contains
stateManager.attach(new MainMenuAppState());
}
In MainMenuAppState.java implements ScreenController {
initialize() {
niftyDisplay = new NiftyJmeDisplay(app.getAssetManager(), app.getInputManager(), app.getAudioRenderer(), app.getGuiViewPort());
// Create a new nifty GUI object
nifty = niftyDisplay.getNifty();
// attach a couple of more app states which also has nothing significant in update loop
// do some good computation
// attach 5 new APP STATES which does not have anything significant in update()
display the appropriate screen of nifty
}
onClick() {
nifty.gotoScreen(“loadScreen”);
// appstate previously attached. they dont have anything significant in update.
// They have significant initialize methods.
app.enqueue(
rgas.reInitialize(time,cameraLoc,cameraRot);
maes.reInitialize(qId); // loads all the scene and models on screen
nifty.gotoScreen(“hudScreen”);
nifty.getScreen(“hudScreen”).findElementByName(“ConfirmModuleButton”).setFocus();
ppes.reInitialize(); // this contains input mappings
);
}
}
If there is a way to do this it will be on the InputManager so you could check out the API for that. Your problem may be though that the queue isn't really a queue in the way you are thinking. Potentially it is not a queue of input events but a queue of actions being taken in response to the events. Since events don't process until the update loop runs them then if the upload loop is stalled they will keep building up.
You could simply not add the listeners until the application has finished loading, then any events will get ignored automatically. You could also try breaking the scene loading up using a queue or similar of your own to load things a bit at a time while not completely stalling the system.
You may get a better response on this question if you try the jME3 forums. There are more monkeys active there than here including people with more detailed knowledge of the input system than me :)
I guess what Tim B said is your best bet.
However you could try calling nifty.setIgnoreMouseEvents(true) and nifty.setIgnoreKeyboardEvents(true) at some appropriate time to shut-off handling of any events that might reach Nifty and enable it later again.
Related
This question already has an answer here:
How to stop Java from running the entire code with out waiting for Gui input from The user
(1 answer)
Closed 5 years ago.
I'm a rather basic programmer who has been assigned to make a GUI program without any prior experience with creating a GUI. Using NetBeans, I managed to design what I feel the GUI should look like, and what some of the buttons should do when pressed, but the main program doesn't wait for the user's input before continuing. My question is, how do I make this program wait for input?
public class UnoMain {
public static void main(String args[]) {
UnoGUI form = new UnoGUI(); // GUI class instance
// NetBeans allowed me to design some dialog boxes alongside the main JFrame, so
form.gameSetupDialog.setVisible(true); // This is how I'm trying to use a dialog box
/* Right around here is the first part of the problem.
* I don't know how to make the program wait for the dialog to complete.
* It should wait for a submission by a button named playerCountButton.
* After the dialog is complete it's supposed to hide too but it doesn't do that either. */
Uno Game = new Uno(form.Players); // Game instance is started
form.setVisible(true); // Main GUI made visible
boolean beingPlayed = true; // Variable dictating if player still wishes to play.
form.playerCountLabel.setText("Players: " + Game.Players.size()); // A GUI label reflects the number of players input by the user in the dialog box.
while (beingPlayed) {
if (!Game.getCompleted()) // While the game runs, two general functions are repeatedly called.
{
Player activePlayer = Game.Players.get(Game.getWhoseTurn());
// There are CPU players, which do their thing automatically...
Game.Turn(activePlayer);
// And human players which require input before continuing.
/* Second part of the problem:
* if activePlayer's strategy == manual/human
* wait for GUI input from either a button named
* playButton or a button named passButton */
Game.advanceTurn();
// GUI updating code //
}
}
}
}
I've spent about three days trying to figure out how to integrate my code and GUI, so I would be grateful if someone could show me how to make this one thing work. If you need any other information to help me, please ask.
EDIT: Basically, the professor assigned us to make a game of Uno with a GUI. There can be computer and human players, the numbers of which are determined by the user at the beginning of the game. I coded the entire thing console-based at first to get the core of the game to work, and have since tried to design a GUI; currently this GUI only displays information about the game while it's running, but I'm not sure how to allow the code to wait for and receive input from the GUI without the program charging on ahead. I've investigated other StackOverflow questions like this, this, this, or this, but I cannot comprehend how to apply the answers to my own code. If possible, I'd like an answer similar to the answers in the links (an answer with code I can examine and/or use). I apologize if I sound demanding or uneducated and confusing; I've been working diligently on this project for a couple weeks and it's now due tomorrow, and I've been stressing because I can't advance until I figure this out.
TL;DR - How do I get my main program to wait and listen for a button click event? Should I use modal dialog boxes, or is there some other way to do it? In either case, what code needs to be changed to do it?
Unlike console based programming, that typically has a well defined execution path, GUI apps operate within a event driven environment. Events come in from the outside and you react to them. There are many types of events that might occur, but typically, we're interested in those generate by the user, via mouse clicks and keyboard input.
This changes the way an GUI application works.
For example, you will need to get rid of your while loop, as this is a very dangerous thing to do in a GUI environment, as it will typically "freeze" the application, making it look like your application has hung (in essence it has).
Instead, you would provide a serious of listeners on your UI controls that respond to user input and update some kind of model, that may effect other controls on your UI.
So, to try and answer your question, you kind of don't (wait for user input), the application already is, but you capture that input via listeners and act upon them as required.
It is bad practice to do big jobs on the UI thread as if you do, those big jobs will cause the program to hang (not accept user input or render any new data) until that job is finished.
I am looking to add a widget to our code base that will indicate to developers when they have committed this taboo. My idea, and one I've seen on a number of other applications, is to have some component that is constantly moving at a constant speed, such as a bar that is constantly twirling on the screen. With such a tool, if a developer is working and accidentally does something that is more computationally difficult than he expected on the UI thread, this spinning bar will become choppy, indicating to him, when he does functional testing, that he needs to implement mechanisms that will cause this job to be executed elsewhere.
One odd requirement on this code is that it should be completely non-existent in production builds, and only present in dev builds, since it is a widget not for users, but for developers.
I jumped into the Canvas objects and wrote up a quick component that simply spins a teal bar. The idea is that if a big job is dumped on the UI thread, the bar will stop spinning (since the FX job queue wont continue dispatching) and the bar will jump forward, rather than rotate smoothly (as it does when the program is at rest).
Below is a screen-shot of this first implementation:
(notice the teal bars, which, if you saw our application running, would be rotating slowly but steadily --hopefully anyways)
The issue here (as you might notice) is that our layout's been screwed up. This is because I'm modifying the scene graph from this:
Scene
RootComponent
Content
to
Scene
obnoxiousPane
Canvas
Spinner(s)
RootComponent
Content
Modifying the scene graph in such a way has things like preferred height, mouse events and (presumably) any number of other events getting dispatched to the spinners rather than the content components.
Of course, when we go to production, I would like to have the original scene graph in the version that we give to our users.
So my question is this: How should I go about correcting these problems?
I could go after each of them individually as they come up, writing a lot of custom code to do things like
obnoxiousPane.prefHeightProperty().bind(content.prefHeightProperty)
obnoxiousPane.prefWidthProperty()//...
spinner.setMouseTransparent(true)
spinner.setOtherEventsIProbablyCantEnumerateWithoutSeriousResearchTransparent(true)
Or I could try to go after this problem with reflection, attempting to bind every property in the content pane to the corresponding obnoxiousPane property, but this seems like a bug breeding ground.
Or... what? I'm hoping there's some LightWeight component or ImNotReallyHereProperty that I can leverage to add this development aid.
Thanks for any help!
Your approach seems fundamentally flawed. You shouldn't be stalling the JavaFX application thread.
Instead you should have a concurrent process and update the UI as appropriate as the process starts, progresses and completes.
See this java2s sample for using the JavaFX concurrency and progress indicator facilities for an example of such an alternate approach.
If you want to disable some portion of the UI for a time, nodes have a disabled property which you can set. You can use CSS to style a disabled node so the user has some indication that the thing hasn't just hung and is deliberately disabled.
Sorry the title is fuzzy, but I really coudln't come up with a fitting title.
I'm developing my first application with Swing, and I'm having a hard time figuring out how to keep track of the current view of the application. With I mean with current view is for example if a button has already been pushed. For example, you shouldn't be able to press "Execute" before a file has even been loaded. I've come up with an architechtural solution to this that is really crappy, and I'd like tips on how to improve it.
I have a label called infoText, and it's updated pretty much every time I press a button. Through this, I'm keeping track of the applications state in this fugly way:
if (infoText == LOADING_NARROW){
printSelected(narrow_list);
}else{
printSelected(list);
}
Rather than keeping track of your state with GUI components, use normal Java objects and variables.
Just keep a boolean loadingNarrow in this case that you reference and update when needed.
Also if you are running a large load as the result of a button press and don't want the user to press it again you can disable the button once the load starts and re-enable it later. (Note I am assuming you are running the load on a separate thread so the GUI does not freeze).
Swing Components keep track of their own states.
My advice:
Initiate the application to a default state.
Adjust the settings in an event driven manner. For instance when JButton A is clicked, enable JButtons B and C and set a JTextField.
Check the states of objects with their builtin methods. Example
if((jButtonA.isEnabled() && jTextField.getText().equals("foobar"))
You can also use the mediator pattern to group related components and their actions.
First: Are they different methods, or a copy-paste-error?
printSelecteds (narrow_list);
printSelected (list);
Second: To disable a button you usually use:
ok.setEnabled (false);
If the file is loaded, you call
ok.setEnabled (true);
to enable the JButton "ok".
I don't see how that is related to your info-text, and to your printSelected(s) method. If you pass the state via the GUI, you might loose the one or the other due to race conditions. Changing a label could be the sink of an state change.
You could have mutual exclusive bit patterns to allow interference:
FILE_OPEN = 1;
SEARCHED = 2;
FRIDAY = 4;
to add them bitwise:
state |= FRIDAY
to ask them up in a binary pattern:
if (state | FILE_OPEN) ....
It doesn't look very elegant to me. I guess I'm not sure what your problem is. :)
To fire an action if some button is pressed, you have to implement an actionListener, which could modify your label as well. But the swing eventloop will already check the state of your components. You seem to duplicate the work partly.
in echo 3 i have a problem setting focus on a specific text field in a new screen. The probelm occurs when a user holds their mouse on the reference button on the previous screen as opposed to just a simple click.
it looks similar to this:
public void display screen {
build window
if window isnt null{
build screen
if screen.textfield isnt null{
Thread t {
thread sleep 10000
screen.textfield.setFocus
}
}
}
}
in the pseudo above the focus would be set if the user user held the reference button down on the screen before for less than 10 seconds, in which case the focus would not be set until the remaining thread time passed. this isnt good because it take too long; and lower wait delay doesnt insure that the focus will set at all because the user might hold the key for longer.
I have tried launching multiple threads and using timers to hammer the focus in but that didnt work... is there something im missing about how the code is built internally because it seems that the whole thing is built despite the fact that the user hasnt let go of the button.
If thats the case is there a way to do it on release?
Thank You
Found a solution. The problem was with using IE6. I presume the order in which it builds is different to that of IE7+.
In my application I fetch data if component is resized. I want to delay the fetch till user completes resize operation. ComponentListener event componentResized fires every time the window is resized.
I'd say you are propably writing a mapping application of some kind? :-)
You can use the swing Timer class to wait until a specified amount of time passed without any events. Here's the code :
/** Time to wait */
private final int DELAY = 1000;
/** Waiting timer */
private javax.swing.Timer waitingTimer;
/**
* Handle resize event.
*/
public void componentResized(ComponentEvent e)
{
if (this.waitingTimer==null)
{
/* Start waiting for DELAY to elapse. */
this.waitingTimer = new Timer(DELAY,this);
this.waitingTimer.start();
}
else
{
/* Event came too soon, swallow it by resetting the timer.. */
this.waitingTimer.restart();
}
}
/**
* Actual resize method
*/
public void applyResize()
{
//...
}
/**
* Handle waitingTimer event
*/
public void actionPerformed(ActionEvent ae)
{
/* Timer finished? */
if (ae.getSource()==this.waitingTimer)
{
/* Stop timer */
this.waitingTimer.stop();
this.waitingTimer = null;
/* Resize */
this.applyResize();
}
}
This isn't possible via conventional means, I'm afraid. componentResized() will be called for every intermediate sizing change, and there is no way to determine if the current call will be the last.
Strictly speaking, what you are attempting isn't a conventional thing to do. Data loads can be expensive IO operations and are usually best performed when the user is expecting them after a more direct UI operation such as a button press, when appropriate feedback can be displayed as a result of their action. The size of a component can change for innocent reasons such as the frame being maximised or arranged as a result of an operation elsewhere, such as the new Aero operations in Windows 7.
Some applications do perform IO as a result of sizing. Google Reader, for instance, can load older posts from RSS feeds as a result of moving the scrollbar on the browser window. This is a nice feature, and does away with the need for an explicit load button, but it is directly driven by the user seeking the older posts; a conscious action, not an unconscious one.
I guess my point is that you need to be very careful about how you make this work. Punishing a user with a slow IO operation that makes them wait simply because they dared resize the window is not a user-friendly approach!
You give precious little information in your question about what your UI looks like, or what the component is or how it gets resized - even, where you are loading data from, so it's kind of difficult to answer. Here are a couple of suggestions: I hope they help.
1. Load the data into memory beforehand, and just display it
If the data model isn't too big you could just load it into memory, and redraw it quickly with every resize event. The Event-Dispatch-Thread will combine resize events together so your listener is not overwhelmed by requests. This might be a non-starter for you, but it's worth mentioning.
2. Be eager to load
Load more data than you need on the first resize event, and then either reject or cache the data you don't use. If you're populating the rows of a table or a list this might be the better approach; tabular data is usually straight-forward to load and parse.
3. Allow a reasonable time to pass for resizing to stop
The first resize event starts a Timer with a 1 second countdown. Any subsequent resize events reset the 1 second countdown. At some point there will be a final resize event after which no subsequent resize events reset the countdown so it is allowed to expire. At this point the Timer does your load for you.
Three is the safest, most accurate approach, in my opinion. You can make your application feel responsive by visibly indicating that data is loading on the first resize event, and adjust the countdown of the timer to get the feel of your application right.
This is not possible. But you can use SingleWorkerThread to minimalize the number of events processed.