We Keep Coding

Libgdx controller unresponsive after making application fullscreen

When making the application full screen with the following call:
Gdx.graphics.setFullscreenMode(Gdx.graphics.getDisplayMode());
I no longer have signals from my controller. The issue is not solved by changing the display back from full screen like:
Gdx.graphics.setWindowedMode(Gdx.graphics.getWidth() / 2, Gdx.graphics.getHeight() / 2);
I'm using Gdx version: 1.9.8. It appears this was an issue fixed in a previous version, but I'm not sure what the necessary steps are to get the work around functioning.
Here's some posts I found about the issue:
https://github.com/libgdx/libgdx/issues/4723
https://github.com/GoranM/bdx/issues/518
(this one is old) http://www.badlogicgames.com/forum/viewtopic.php?f=11&t=10692
Any help is much appreciated.
*Edit: This is using the controller extension that can be checked from the libgdx set up application. *
Edit2: I can get a responsive controller if I re-poll the controllers like the following:
Array<Controller> controllers = Controllers.getControllers();
However, this cannot be done instantly after changing the display mode; I have to wait some amount of time after. I'm not sure what I need to poll to determine how long I have to wait until the controller instances are valid (also, when it is valid to assign a listener).
Edit3: The only solution I've been able to come up with is to set a flag inside the resize callback like the following
#Override
public void resize(int width, int height) {
resizeDirty = true;
resizeTimestamp = System.currentTimeMillis();
}
Then in my main loop call:
private void controllerCheck() {
if (resizeDirty) {
long currentTime = System.currentTimeMillis();
if (currentTime > resizeTimestamp + controllerResetDelay) {
resizeDirty = false;
//get new controller instance | re-add a controller listener
}
}
}
This isn't ideal, I'd rather find a way to listen to when the change in context is done initializing then update the controllers. But I haven't been able to find a hook for that. I'd appreciate it if anyone knows a better way to go about maintaining controllers with change in display mode.

Why don't you try to use the immersive fullscreen?
If the objective is to set the fullscreen mode, I think this is the better way to.

How to get all FeedbackMessages from components inside specific form?

Wicket 6 no longer keeps feedback messages in session. Now they are attached to components, which I think is great move but I approach an issue connected with that. I used to remove all feedback messages that were related to the specific form like this :
Session.get().getFeedbackMessages().clear(new ContainerFeedbackMessageFilter(panelForm));
Unfortunetly right now I can't clear it like this:
panelForm.getFeedbackMessages().clear();
For obvious reasons - they are attached to components inside form.
So is there a way to get those feedback messages by only accesing (in my case) panelForm or my only way to go is to call getFeedbackMessages() on all of my components (panelForm.component1, panelForm.component2 etc)?

use FeedbackCollector as in example:
new FeedbackMessagesModel(this) {
#Override
protected List<FeedbackMessage> collectMessages(Component panel, IFeedbackMessageFilter filter) {
return new FeedbackCollector(YourComponent.this.getParent()) {
#Override
protected boolean shouldRecurseInto(Component component) {
return true; // your citeria here
}
}.setIncludeSession(false).collect(filter);
}
};

Yes. You should use FeedbackCollector. Collect the messages and mark them as rendered.

Custom message when closing a part in Eclipse RCP 4

we have the following problem:
In our Eclipse RCP 4 application there are multiple parts and the parts are closable. When the user is closing a part there should be a custom pop-up (depending on some internal part state) which is asking the user if he really wants to close the part or not.
It seems to be not that easy to implement in Eclipse RCP 4 or we have just totally overseen something.
I'll just give you a short brieifing about the things we tried:
Use dirtable with a #persist method in the part. Though the problem is, we don't want this standard eclipse save dialog. So is there a way to override this?
public int promptToSaveOnClose(): This seemed to be promising but not for Eclipse 4 or is there a way to integrate it that way? Compare: http://e-rcp.blogspot.de/2007/09/prevent-that-rcp-editor-is-closed.html
Our last try was to integrate a custom part listener, simple example shown in the following:
partService.addPartListener(new IPartListener() {
public void partVisible(MPart part) {
}
public void partHidden(MPart part) {
partService.showPart(part, PartState.ACTIVATE);
}
public void partDeactivated(MPart part) {
}
public void partBroughtToTop(MPart part) {
}
public void partActivated(MPart part) {
}
});
The problem with this was we are running into a continuous loop. Something similar is posted over here in the last comment: Detect tab close in Eclipse editor
So I could write some more about this problem, but I think that's enough for the moment. If you need some more input just give me a hint.
Thanks for helping.

The save prompt is generated by the ISaveHandler registered in the context of the MWindow containing the MPart. You can write your own ISaveHandler and set it in the window context to replace the default.
You might also want to look at the IWindowCloseHandler also in the window context.

Thanks greg, this has helped and I was able to achieve changing the pop-up when the user closes a part. Here's a short description of what I've done:
Use the MDirtyable for marking the part as dirty whenever it's needed.
Create a custom save handler which implements ISaveHandler (when a part got closed the save method is called). Add the additional logic to this handler (e.g. a custom message dialog)
Register this handler at application start-up (I just chose a method which is called at the start-up):
#Inject
private MWindow window;
...
ISaveHandler saveHandler = new CustomSaveHandler(shell);
window.getContext().set(ISaveHandler.class, saveHandler);
Note that the registration via a model processor was sadly not that easy because the model processor is called too early. (Take a look at: http://www.eclipse.org/forums/index.php/t/369989/)
The IWindowCloseHandler is just needed when the complete window is closed, though this was not an requirement for us :).

How to use GWT fileupload?

I have some queries when trying to implement a fileupload widget in my application. After many tries, it just doesn't seem to work.
Hence, I tried getting working solutions to see if I can understand anything from there.
http://code.google.com/p/faculty-gwt/source/checkout
However, I tried uploading a file using this and it seems that I am getting error messages too. and what is that textbox and listbox suppose to do? It is meant for showing an example of validating an input before submitting?
Can someone guide me along to solve this? Thanks.

Never tried to use the link you provided, but this is what i did to use a a GWT FileUpload widget:
I built a File Upload widget using the uibinder:
<g:FormPanel ui:field="docForm">
<g:FlowPanel ui:field="inputPane">
/*other displayed info*/
<g:FileUpload ui:field="DocPath"/>
/*other displayed info*/
</g:FlowPanel>
</g:FormPanel>
(Per the GWT api, FileUpload widgets can only be used from a FormPanel)
Make sure you set these in the FormPanel, otherwise you'll probably have issues:
yourFormPanel.setEncoding(FormPanel.ENCODING_MULTIPART);
yourFormPanel.setMethod(FormPanel.METHOD_POST);
That widget is dropped into my container page, then added to the display panel:
private FileUploadWidget createNewUploader(){
FileUploadWidget uploader = new FileUploadWidget(/*my constructor params*/);
uploader.addChangeHandler(new ChangeHandler() {
#Override
public void onChange(ChangeEvent event) {
DocPanel.add(createNewUploader());
}
});
return uploader;
}
My OnChange event is so that I have a new, blank uploader available when i use the current one.
and when I'm ready to submit:
private void processUpload(FileUploadWidget upload, int id) {
upload.setId(id);
//Don't bother to submit an empty one.
if (upload.IsFileSelected())
upload.Submit();
}

How to clear the (CSS) visited history of an Android WebView?

I try to reuse an existing WebView by clearing any private data the previous user left behind:
CookieManager.getInstance().removeAllCookie();
webview.clearHistory();
webview.clearFormData();
webview.clearCache(true);
clearHistory seems only to clear the back/forward list, accessible via API, but not the internal list used for coloring links inside the web content.
I even tried the following, suggested by another stackoverflow answer:
deleteDatabase("webview.db");
deleteDatabase("webviewCache.db");
I still have no luck: CSS :visited selectors still work after reloading the page.
An alternative would be to use the API level 11 private browsing feature (new constructor argument), but then I cannot benefit from visited links at all; and can no longer target older versions.
Maybe someone has a solution for this issue? Thanks for your help.
Summary of the answers I got so far:
I tried these two answers, but the first seems to clear HTML5 data storage and the latter seems to be specific to the built-in browser:
WebStorage.getInstance().deleteAllData();
Browser.clearHistory(getContentResolver());
WebChromeClient.getVisitedHistory(ValueCallback<String[]> callback) is only called after the first time I create a new WebView in a recently installed application.
I tried to remove the WebView from view hierachy and create a new one, but unfortunately the visited history seems to be stored for the whole application.

Override WebChromeClient and WebViewClient... Damn that was hidden.
I actually had to dig up a bit to find this out.
WebView webView = (WebView)findViewById(R.id.myWebView);
WebChromeClient myWebChromeClient = new WebChromeClient(){
#Override
public void getVisitedHistory(ValueCallback<String[]> callback) {
// called during webview initialization, original implementation does strictly nothing
// and defaults to the native method WebViewCore.nativeProvideVisitedHistory()
String[] myUserHistory = getVisitedUrlsFromMyOwnDatabase(userId);
callback.onReceiveValue(myUserHistory);
}
};
WebViewClient myWebViewClient = new WebViewClient(){
#Override
public void doUpdateVisitedHistory(WebView view, String url,
boolean isReload) {
// called whenever there is a new link being visited
insertIfNotExistVisitedUrlIntoMyOwnDatabaseForUser(userId);
super(view, url, isReload);
}
}
webView.setWebViewClient(myWebViewClient);
webView.setChromeClient(myWebChromeClient);
webView.getSettings().etc(whatever)...
I think I'm "almost there". Here's the part I managed: what it does so far is remove css history altogether, so we're halfway there. I can't get the browser to recognize the url format I'm providing in "myUserHistory", so in effect the only feature this code does is reset css history altogether, but it's only called once when the WebView is instanciated (or created, didn't check), so for a true multiuser experience you'd need to recreate the webview at each login.
My problem now is that I can't manage to load the urlHistory properly. My Honeycomb Xoom webview seems to ignore my data.
Ah well, I hope it works for you. For me just calling callback.onReceiveValue(new String[]{}); in getVisitedHistory() will be good enough.
EDIT:
I just put twenty more minutes into it because I'm curious. This method is what delegates to the WebChromeClient (mCallbackProxy = WebChromeClient).
protected void populateVisitedLinks() {
ValueCallback callback = new ValueCallback<String[]>() {
public void onReceiveValue(String[] value) {
sendMessage(EventHub.POPULATE_VISITED_LINKS, (Object)value);
}
};
mCallbackProxy.getVisitedHistory(callback);
}
It's protected in WebViewCore, which is a private attribute of WebView with no accessor. The sendMessage delegates to EventHub which is private, and WebViewCore is filled with private native methods, and one of these seems to be the one actually calling the populateVisitedLinks() method during the initialization.
Unless someone at Google adds a public method to WebView to trigger the repopulation, I'm afraid it's practically impossible to achieve your goal. Sorry :(
As a side note, all these native visited history handling really makes me wonder: why do hardware manufacturers care so much about which urls we visited? ;) <<< sarcasm

As an alternate solution, you could try adding your own CSS with the same base colors the default CSS has and switch the CSS by another one (with same color for both "types" of links) when you want to reset the visited links.
A:link{color: "#990000"; text-decoration: none;}
A:visited{color: "#990000"; text-decoration: none;}
A:hover{color: "#ff0000"; text-decoration: none;}

If you can obtain a Browser instance (maybe you can set a WebChromeClient to WebView) you can use its clearHistory() method.

Does WebStorage.clearAllData() have the desired effect? Unfortunately, the documentation on this class is very sparse compared to WebView and doesn't say whether it applies to WebViews.
The exact time you're calling clearHistory() may also have an effect. Clearing it and then navigating to a new page may still keep the first page in history, and you have to call the method after the new page has loaded.
Personally, if privacy is a real issue, I would create a new set of objects from scratch for this new session if possible.