Titling this was awkward, but basically I'm trying to close a JFrame that allows the user to change their password. I know to use the dispose() to close it, but I have a delay timer so the user can see feedback that their password was changed before closing the JFrame. In my initial testing, I forgot to end the delay timer, so when it opened the programs main frame, it continued to open more and more of the program's main frame until I close the program. I then obviously went in and stopped the timer.
This has told me something that kinda worries me, that when disposing the frame, it's still running code. This worries me, it makes me worry that there's a chance that the user could break something or the program could begin to lag with long use if code is still running in the background unnecessarily. Is there a way to actually end the code of the JFrame when its disposed, or is stopping the timer itself the only answer here?
In this case I'm assuming that stopping the timer will stop any background code from running, but if the frame is still active, it makes me worried about the possibilities with other frames that have more interactivity that are being closed and reopened.
EDIT:
I should have explained better. For the actual frame's closing option, I have it as this.setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE); so that the user can't close it without saving their new password or cancelling the password change.
In the save button function, I have:
delayTimer.start();
And for the actual timer:
if (e.getSource() == delayTimer)
{
new MainFrame();
this.dispose();
delayTimer.stop();
}
Related
I have an unrepeatable bug of unknown origin in my single threaded window manager that occurs fairly infrequently (once every 2-3 weeks). Something happens that causes me to lose keyboard input. Mouse events are still handled properly so I know the event loop is still running, but the key press event is no longer triggered. Actually, the key is no longer grabbed. When I press XCB_MOD_MASK_4+2 to switch to desktop 2, the 2 will show up in the text editor or terminal that currently has the input focus, instead of being grabbed by the window manager. I thought maybe it was related to xcb_allow_events, so via IPC I can execute these three tests (from within the window manager, cmd is received from an external process):
if (strcmp(cmd,"test0")==0)
xcb_allow_events(wm.conn, XCB_ALLOW_ASYNC_KEYBOARD, XCB_CURRENT_TIME);
else if (strcmp(cmd,"test1")==0)
xcb_allow_events(wm.conn, XCB_ALLOW_SYNC_KEYBOARD, XCB_CURRENT_TIME);
else if (strcmp(cmd,"test2")==0)
keyboard();
void keyboard()
{
int i,m,k;
xcb_void_cookie_t cookie;
spawn("/usr/bin/xmodmap -e 'keycode 108 = Super_L'");
spawn("/usr/bin/xmodmap -e 'remove mod1 = Super_L'");
for (i=0; i<LENGTH(key_bindings); i++)
{
m = key_bindings[i].mod;
k = keysc(key_bindings[i].keysym);
info("grabbing key: %s (%d), mod: %d",key_bindings[i].keysym,k,m);
cookie = xcb_grab_key_checked(wm.conn, 0, wm.root, m, k, XCB_GRAB_MODE_ASYNC, XCB_GRAB_MODE_ASYNC);
if (xcb_request_check (wm.conn, cookie))
error("can't grab key");
}
}
None of these tests help. I know the keyboard function works properly because it works on window manager startup. Also I can see in the log file that the key grabs in the keyboard function are actually being executed (without error) when prompted via IPC. The current workaround is to send sigterm to the window manager process, and then restart the wm. At that point everything works fine again.
I'm looking for techniques that might be helpful in tracking down the source of this problem, or in correcting the problem once it occurs (another test). Unfortunately, since I have no clue of the source of this problem, or what triggers it, I cannot make a simple test case to demonstrate. BTW I check the log files when this happens, and I don't see any pattern leading up to the problem. Each function logs an entry on entrance and exit.
Update 2021-02-12: I thought a restart would be a good workaround until I found the root cause of this problem. My restart function contains only one line:
execvp(lwm_argv[0], lwm_argv);
where lwm_argv is the argv provided as an argument to main.
I was very surprised to see that this did not alleviate the problem. I have to completely kill the old process then launch an new one to alleviate the problem. So this problem is PID dependant??? Further, I'm fairly convinced that this problem is somehow related to the stdout/stderr output of other applications launched from within the window manager using execvp. I've stopped launching applications from within the window manager and the problem went away. Any ideas of how launching other applications (and their output) could be affecting the keygrabs within the window manager would be appreciated.
You could try using strace or perf trace on the X server to see what it is doing with the key events. It ought to read them from somewhere in /dev/input and send them as events to connected clients.
If it isn't sending you events, then you might need to dig into its internal state, perhaps by building a debug server and connecting to it with GDB, to see why it isn't sending those events.
But if it is sending events to your WM then they're getting lost somewhere in the library stack.
I'm using the ToastBar messages with timeout 6 seconds. If I click another button within 6 seconds which will display another toastbar message, second one will overlap with first one in some instances. How can a dispose first message and display second message without overlapping if the button is clicked before timeout occurs. Please advise.
ToastBar.showErrorMessage("Test Message", 6000);
Thanks
Make sure you are always invoking this method from the EDT and not from a separate thread e.g. the network thread. Use the edt error detection tool in the simulator to try and track such issues.
I have the same issue. First I tried to make sure that I do not call each message using the same object reference, but also use local variable instances to allow the Garbage Collector (GC) dispose them since the instance is discarded when the task is done.
However, this may take some time and the message still appears overlapping or even worse, it repeats itself with out a trigger, but less likely (infrequent) now because the GC collects the object.
It may be tempting to call the GC manually if possible, but then you need to assess performance impact.
I have not attempted yet the approach I am about to suggest, but let me know what you think.
Making it so, that ToastBar messages appear one on top of the other when triggered. Maybe a List<ToastBar> object or other similar may prove useful. This may be described as a ToastBar "buffer".
The other way around is to clear() the message but then if it is too long it will not allow the user the necessary time to read the feedback.
I have this in my TODO list but will follow up when I make some additional progress.
I want to log if a customer tries to force close the application. I'm aware of having no chance to catch a process kill. But it should be possible through the main form closing event to get informed about the 'CloseReason.TaskManagerClosing' reason.
But any tests I did under Windows 8.1 I always got a CloseReason.UserClosing reason. But in this case (compared to a normals CloseReason.UserClosing) I've about 0.2s to run user code afterwards my program is killed!
Is this a new behavior in Windows 8.1?
Yes, I see this. And yes, this is a Windows change, previous versions of Task Manager sent the window the WM_CLOSE notification directly. I now see it issue the exact same command that's issued when you close the window with the Close button (WM_SYSCOMMAND, SC_CLOSE). Or press Alt+F4 or use the system menu. So Winforms can no longer tell the difference between the Task Manager and the user closing the window and you do get CloseReason.UserClosing.
What happens next is expected, if you don't respond to the close command quickly enough then Task Manager summarily assassinates your program with TerminateProcess().
Do keep in mind that trying to save data when the user aborts your program through Task Manager is a bad practice. Your user will normally use this if your program is malfunctioning, you can't really trust the data anymore and you risk writing garbage. This is now compounded by your saving code being aborted, high odds for a partially written file or dbase data that isn't usable anymore.
There is no simple workaround for this, the odds that Windows is going to be patched to restore old behavior are very close to zero. It is very important that you save your data in a transactional way so you don't destroy valuable data if the saving code is aborted. Use File.Replace() for file data, use a dbase transaction for dbase writes.
An imperfect way to detect this condition is by using the Form.Deactivate and Activate events. If you saw the Deactivate event and the FormClosing event fires then reasonable odds that another program is terminating yours.
But the normal way you deal with this is the common one, if the user ends the program without saving data then you display a dialog that asks whether to save data. Task Manager ensures that this doesn't go further than that.
Another solution for determining when the Task Manager is closing the program is by checking if the main form, or any of its controls, has focus. When you close via the Task Manager, the application is not focused, whereas if you close via the close button or Alt+F4, the application does have focus. I used a simple if check:
private void MyForm_Closing(object sender, FormClosingEventArgs e)
{
if (this.ContainsFocus)
{
// Put user close code here
}
}
I'm trying to make an application like Launchy/Enso/etc., which pops up when the user presses the Caps Lock key.
To do this, I have needed to install a low-level keyboard hook (WH_KEYBOARD_LL), from which I subsequently spawn a thread to display the dialog to present to the user.
The trouble is, when I somehow steal focus (e.g. by clicking on another window) and subsequently press Caps Lock with a short delay, my window doesn't get the keyboard input: the input goes to the background window, even though my window is "active" (from looking at the title bar).
Of course, this gets pretty annoying, since I then end up typing something like "visu" (for "Visual Studio") inside a text processor (or a chat box...) and pressing Enter, withotu realizing that it didn't do what I intended.
(Funny thing is, after a 3-second (or so) pause, my window's title bar suddenly becomes "inactive", even though it was never active in the first place!)
How can I bypass this "protection" mechanism to actually activate my window?
Okay, I finally figured out a hack. (Microsoft employers: please look away...)
I intercept Caps Lock with a low-level keyboard hook, then when I detect VK_CAPITAL, I call
keybd_event(
VK_OEM_8,
(BYTE)MapVirtualKey(pKBDLLHook->vkCode, MAPVK_VK_TO_VSC),
(wParam == WM_KEYUP || wParam == WM_SYSKEYUP) ? KEYEVENTF_KEYUP : 0,
0
);
from within the handler.
Essentially, I just change the request to VK_OEM_8.
However, Notice that the virtual-key code does not correspond to the scan code. This is intentional -- VK_OEM_8 doesn't have a scan code (as far as I could tell, anyway) so I didn't have much of an option.
Then I just program based on VK_OEM_8 instead -- which is easy to intercept/handle/etc.
Hope this helps out other people.
I am designing an application which has the potential to hang while waiting for data from servers (either Database or internet) the problem is that I don't know how best to cope with the multitude of different places things may take time.
I am happy to display a 'loading' dialog to the user while access is happening but ideally I don't want this to flick up and disappear for short running operations.
Microsoft word appears to handle this quite nicely, as if you click a button and the operation takes a long time, after a few seconds you get a 'working..' dialog. The operation is still synchronous and you can't interrupt the operation. However if the same operation happens quickly you obviously don't get the dialog.
I am happy(ish) to devise some generic background worker thread handler and 99% of my data processing is already done in static atomic methods, but I would like to go best practice on this one if I can.
If anyone has patterns, code or suggestions I welcome them all
Cheers
I would definitely think asynchronously using a pattern with 2 events. The first "event" is that you actually got your data from wherever/whenever you had to wait for it. The second event is a delay timer. If you get your data before this timer pops, all is well and good. If not, THEN you pop up your "I'm busy" and allow them to cancel the request. Usually cancel just mean "ignore" when you finally get the response.
Microsoft word appears to handle this quite nicely, as if you click a button and the operation takes a long time, after a few seconds you get a 'working..' dialog. The operation is still synchronous and you can't interrupt the operation. However if the same operation happens quickly you obviously don't get the dialog.
If this is the behavior your want...
You could handle this, fairly easily, by wrapping a class around BackgroundWorker. Just time the start of the DoWork event, and the time to the first progress report. If a certain amount of time passes, you could show your dialog - otherwise, block (since it's a short process).
That being said, any time you're doing work that can be processed asynchronously, I'd recommend doing it that way. It's much nicer to never block your UI for a noticable interval, even if it's short. This becomes much simpler in .NET 4 (or 3.5 with Rx framework) by using the task parallel library.
Ideally you should be running any IO or non-UI processing either in a background thread or asynchronously to avoid locking up the UI.