NetBeans Platform App - Window control - java

I'm learning the NetBeans Platform and I've gone through a few tutorials and started working on a app. I've implemented the login tutorial with some changes which include 3 levels of access for a text editing application. The access levels are User, Admin, and None. Based on access level different options will be available. If the user has None, then I want to stop the window from opening and instead present a dialog indicating they don't have permission to use the module. I can't figure out how to keep the window from loading. The permissions check is within the top component constructor but I don't know how to make the window self-close.
I tried doing an immediate return from the constructor but that leaves an empty tab in the editor area. I've tried this.close(), variations on trying to get the WindowManager, etc., with no luck.
How can I make the window either not open or close immediately?

Call this.close() in the componentActivated() method of the top component. Make sure to call super.componentActivated(); before calling this.close()

Related

How can Take permission using an alert Box at just destroy the application in Android

I just want to show an alert box at just killing the application in android.
It's like a Notepad application, if we simply kill the app (on clicking the close button) then we get an alert box asking for save changes.
I just want to add same thing in my application.I have tried onBackPressed() and its working fine on clicking on Back Button. But I need same thing on closing the application.
There is now way to be sure if the app is being closed but you can place a check if the application is in foreground or not which is a better metric IMHO as this tells you when the user moved away from your application.
To check the ProcessLifeCycleOwner this will help you find state of process. You can check this Github sample or this stackoverflow question in how to use it.

Use .getWindow() in Application-file

This may be a silly question but I have the following situation: I want to setup my window layout every time the app is open, for example changing the status bar color. So I created my Application file because I heard it is better if you check something like this in the application file and not in the MainActivity.
Problem: How can I call the getWindow() method without an open activity.
Thanks for helping.
A bit tricky, but you can use Window manager in background-service to display your views without opening an Activity.
Also, for API Level 26+ (Oreo or above) you have to start your service as foreground service

How can I get rid of the "back" button in my j2me programms while using LWUIT?

I'm writing a j2me application using LWUIT. I make a GUI in the LWUIT Resource Editor. But there's a little problem: when I switch through the Forms in my mobile application, the "back" soft button appears (it's task is to move user to the previous form). It turns out, however, that it's ineptly in my program. So, how can I get rid of it? If possible, how can I do so through a quite comfortable LWUIT Resource Editor (the whole GUI is made in it).
The Form object have a method to capture the default back Command. This method is the following Form API getBackCommand
Use this method to get the back Commandand after that, remove it with the Form.removeCommand(backCommand)
If this doesn't work, take a look in the Commands added in the resource editor. The resource editor always add a back Command when the Form is the navigation of the program

Home button brings back to my app

I am making a car launcher application, which contains shortcuts to other apps, when i'm in another app i'd like to press the home button and go back to my launcher
So basically i need to override the home button outside of my app,the override has to work only when my app is opened in the background so when i close my app the home button will work as usual taking you to your default launcher
Can i implement something like this or i'm asking too much?
There is no way to intercept the home button on Android, unless you make your app the home screen. This is for security reasons, so that malicious apps cannot take over your device by overriding all the buttons that can exit. The home button is the one sure shot way to be able to leave any app.
In short, no it's not possible, and even if it were, it is a serious disruption in what a user expects out of an app's behavior.
If you go the route of making your app act be a replacement home screen you'll have to include in the install instructions for the users to set your app as the default launcher.
Then the home button would take them to your app. In order to get it to switch back to the default launcher when they are not in "car" mode would be a bit tricky but you could prolly achieve it with some sort of fork activity that checks if car mode is enabled if so go to your car mode launcher if not go to the default launcher (it gets trickier if the user already has a different 3rd party launcher) So essentially your app will always be the home screen app no matter if car mode is enabled or not, but if it is not then you manually start the "normal" home screen.

Kiosk mode for Linux Java Swing application

How can I disable OS-level keyboard shortcuts (e.g. Alt-Tab, Ctrl-Alt-Left/Right, etc.) on a [Ubuntu] Linux machine? I'm developing a full-screen Java Swing app and don't want the user to be able to task switch away from the program arbitrarily. It's not enough to toggle the "always on top" flag; users mustn't be allowed to switch workspaces, migrate focus or any other such things. The machine must function normally before and after the application is executed. Google says that this will require JNI or JNA but I'm looking for a bit more hand-holding.
There's no point in trying to do this in your application because any of these changes are going to need to be handled by X11 and/or the window manager since those are what respond to the commands. Assuming that you have control of the platform, choose a window manager which supports a kiosk mode. Then use the window manager's settings to start your application and enter kiosk mode.
Options for window managers which can do this include KDE or twm-kiosk.
(And if you don't have control of the platform, you're not likely to be able to have your application intercept things like ctrl-alt-backspace anyway.)
Edit:
In response to a scaled-down version of the question in which he's willing to let things like ctl-alt-backspace go and just wants most of the keys including alt-tab or other similar application switching key combinations, the following should work:
You should be able to do this using XLib's XGrabKeyboard method through JNI. This Java/XLib JNI keypress capture tutorial should be a good starting point. However, it uses XGrabKey which just passively listens for keys and does not prevent other applications from receiving them. You'll instead want to use XGrabKeyboard which actively snags all of the normal keyboard events (which, if the premise of this StackOverflow question is correct, includes the task switching keys).
Note that as a side-effect, key capture in Swing will also probably stop working because your Swing windows are going to be separate from the window you create in C. As such, you will probably have to use your JNI interface to get key presses to your program when needed. (Although I would definitely advise testing it first before writing the code.) You might be able to avoid this if you can get the window using Java AWT Native Interface to get the window ID. (Note that Swing is built on top of AWT, so this will work for Swing.) However, I'm not sure how to do this. It looks like you might be able to navigate the window tree by getting the root window from the Display and going from there to find your Window, but it's all kind of weird. It would be nice if the AWT NI just told you the window ID, but it doesn't look like it does that.
As this warning Reminder: XGrabKeyboard is not a security interface notes, this doesn't make it impossible for other programs to see the keys, but it seems likely that window managers will not be using XQueryKeyMap so it is likely to prevent task switching.

Categories