Hopefully this isn't too difficult to follow.
I'm currently working on a small timelogging application that runs quietly in the background. Every time the ticker runs down, the application prompts the user to say what he/she was doing since the last prompt. I'll eventually have the application write the data into a spreadsheet.
One of the options I have so far enables the user to choose whether or not he/she would like to use the default prompting setting (every time a prompt is missed, it stays visible until the next one is created, meaning if the user leaves his/her computer for a while there may be a fair few prompts sitting on the screen waiting to be filled in) or would like to combine all the prompts (every time a prompt is missed and a new one pops up, the old one is closed and the new one covers the time of the old prompt and the new prompt).
The user can also select a tickbox to turn prompts off. When he/she turns prompts back on again, a prompt pops up asking the user to fill in what he/she was doing while prompts were turned off (useful when the user is running fullscreen applications, etc).
My problem is, when I try to generate the prompts, they don't display correctly. I can't manipulate them at all and none of the controls display. They basically look like empty forms.
Here's my code for generating prompts using the ticker:
public void ticker(object source, System.Timers.ElapsedEventArgs e)
{
if (groupMissed)
{
incrementsMissed += 1;
if (incrementsMissed > 1)
{
IncrementForm form = (IncrementForm)Application.OpenForms["IncrementForm"];
if (form.InvokeRequired)
{
form.Invoke(new MethodInvoker(delegate { form.Close(); }));
}
}
}
else
{
incrementsMissed = 1;
}
IncrementForm theIncrementForm = new IncrementForm(this, e.SignalTime);
theIncrementForm.Show();
latestIncrement = e.SignalTime;
}
And here's my code for generating prompts using the "turn prompts off" checkbox:
private void chkbxAlerts_Click(object sender, EventArgs e)
{
if (!chkbxAlerts.Checked)
{
// Ensures that the time missed is covered and restarts the timer
DateTime now;
now = DateTime.Now;
if ((now - latestIncrement).TotalMinutes >= 1) // Only records time if it is equal to or greater than one minute
{
// TO-DO: FIX
if (groupMissed)
{
incrementsMissed += 1;
if (incrementsMissed > 1)
{
IncrementForm form = (IncrementForm)Application.OpenForms["IncrementForm"];
if (form.InvokeRequired)
{
form.Invoke(new MethodInvoker(delegate { form.Close(); }));
}
}
}
else
{
incrementsMissed = 1;
}
IncrementForm theIncrementForm = new IncrementForm(this, now, latestIncrement);
theIncrementForm.Show();
latestIncrement = now;
}
timer.Enabled = true;
}
else
{
// Stops the timer
timer.Enabled = false;
}
}
If you need any further clarification, please let me know. Thanks so much in advance for any help, this has been bugging me.
System.Timers.Timer has a SynchronizingObject property. If you set that to the main form (or the form that contains the timer), then the timer tick event will be raised on the GUI thread.
Do note that System.Timers.Timer has the nasty habit of swallowing exceptions that occur in the Elapsed event. If your tick handler throws an exception, you'll never see it. It's a nasty bug hider. For that reason, I recommend using either System.Windows.Forms.Timer or System.Threading.Timer. If you use the Windows Forms timer, the elapsed event is raised on the GUI thread. If you use System.Threading.Timer, you'll have to use Invoke as NSGaga shows in his answer.
See Swallowing exceptions is hiding bugs for more information about why I discourage the use of System.Timers.Timer.
I think, from what I can see, not 100% but your timer is spawning your windows in a separate thread (being from the timer ticker call).
While theoretically that can work (take a look at this How to open a form in a thread and force it to stay open)
...you may be much better off staying within the main thread.
Try something like this...
yourMainWindow.Invoke(new MethodInvoker(() =>
{
IncrementForm theIncrementForm = new IncrementForm(this, e.SignalTime);
theIncrementForm.Show();
latestIncrement = e.SignalTime;
}));
...that's from your timer - that way (as I can see) you should have it all 'on the main thread' and make things much easier for you.
hope this helps
Related
I'm making a quiz game and want to make sure that the user does not get additional answering time by exiting the app (without shutting it down).
My current timer uses Time.deltaTime. I'm thinking of replacing this with something like DateTimeOffset.Now.ToUnixTimeMilliseconds() (epoch time) or Time.realtimeSinceStartup (not sure if this one works). A solution to detect when the user closes the app would also work.
There are three built-in functions that might do what you want. There is OnApplication.Quit (does not work on mobile), OnApplication.Pause, and OnApplicationFocus.
I personally like using OnApplicationPause instead of OnApplicationFocus as focus is called on some phones when the keyboard is brought up. I have found that pause is called whenever a user hits the home button, closes the app, their phone dies, turns off their phone, etc.
The great part about the OnApplicationFocus and OnApplicationPause is that there is a bool parameter passed in to let you know whether you are unfocused or focused / unpaused or paused.
If you just want to know how long it has been since the last time the app is opened, you can easily stored a variable locally after an OnApplicationPause is called when the bool is true, then when it is false, you can detect how much time has elapsed. As the local variable will not persist if the user quits the game, you will need to also look into some sort of save/load implementation. There are already many good answers on StackOverflow for how to save data in Unity, so if you need help with that I can add a link.
As for the OnPause example here is how I would use it.
private long lastTimePaused = 0;
private void Awake
{
// setting our paused time to the start time
lastTimePaused = DateTimeOffset.Now.ToUnixTimeMilliseconds();
}
void OnApplicationPause(bool pauseStatus)
{
if(pauseStatus)
{
lastTimePaused = DateTimeOffset.Now.ToUnixTimeMilliseconds();
// save this lastTimePaused if you want the data to persist between a user quitting the app
// and coming back
}
else
{
Debug.Log("Our elapsed miliseconds is: " + (DateTimeOffset.Now.ToUnixTimeMilliseconds() - lastTimePaused));
}
}
If you like, you can also use OnApplicationFocus together with OnApplicationPause. Something like:
private long lastTimePaused = 0;
private void Awake
{
// setting our paused time to the start time
lastTimePaused = DateTimeOffset.Now.ToUnixTimeMilliseconds();
}
void OnApplicationPause(bool pauseStatus)
{
HandlePause(pauseStatus);
}
void OnApplicationFocus(bool hasFocus)
{
HandlePause(!hasFocus);
}
private void HandlePause(bool isPaused)
{
if(isPaused)
{
lastTimePaused = DateTimeOffset.Now.ToUnixTimeMilliseconds();
// save this lastTimePaused if you want the data to persist between a user quitting the app
// and coming back
}
else
{
Debug.Log("Our elapsed miliseconds is: " + (DateTimeOffset.Now.ToUnixTimeMilliseconds() - lastTimePaused));
}
}
I am not sure what cases you would like to detect when a user is suspended, but first, try OnApplicationPause to see if it handles everything you need. If it does not, you can also combine it with OnApplicationFocus.
A form should open only when there is an event if there is no event it should not display on the screen. So Basically i thought of using a timer to do this. An exe will continously be running and after every minute it checks the db to see if there is data and if there is it shows up on the screen and will only be closed manually with user interaction. After a minute it checks again and displays the form if Data is present in the DB.
I used system.threading.Timer in Program.cs file to open a window after every minute.Below is the code
timer = new System.Threading.Timer((s) => {
EL.CustomMessageBox l = new EL.CustomMessageBox();
l.ShowDialog();
}, null, TimeSpan.Zero, 60000);
After certain time I see that this exe is still running in the taskmanager but even though there is data in the DB it stops showing up on the screen. Any help is appreciated.
System.Threading.Timer runs its callback on a threadpool thread. You should never use a threadpool thread for UI work, because:
They don't run a message dispatch loop.
You don't control when the thread gets recycled. UI windows have thread affinity and if their thread exits all the associated windows go poof immediately (you won't even get WM_DESTROY messages).
A normal Application.Run loop on the main thread, with a hidden main window and a UI timer will serve you much better.
I would pass my own custom ApplicationContext to Application.Run() in program.cs.
This will allow you to have NO INTERFACE until your conditions are met. The application will also continue to run (even when you close the Forms) until you explicitly call Application.Exit().
You can keep a reference to your Form at class level. This will help you decide if you need to work with the existing one, or create a new one.
Note that I'm using the System.Windows.Forms.Timer, not the threaded timer.
Something like...
static class Program
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new MyContext());
}
}
public class MyContext : ApplicationContext
{
private EL.CustomMessageBox l = null;
private System.Windows.Forms.Timer timer;
public MyContext()
{
timer = new System.Windows.Forms.Timer();
timer.Interval = (int)TimeSpan.FromMinutes(1).TotalMilliseconds;
timer.Tick += Timer_Tick;
timer.Start();
}
private void Timer_Tick(object sender, EventArgs e)
{
bool result = true; // hit the database and get an answer
if (result)
{
if (l == null || l.IsDisposed)
{
// no form has been created yet, or the previous one was closed
// create a new instance
l = new EL.CustomMessageBox();
l.Show();
}
else
{
// if we get in here, then the previous form is still being displayed
// if your form can be minimized, you might need to restore it
// if (l.WindowState == FormWindowState.Minimized)
// {
// restore the window in here?
// }
}
// update the form "l" with some data?
l.xxx = yyy;
}
}
}
I can't help but think that the other answers, massively technically correct as they are, don't actually solve the problem because they probably don't make sense if you aren't aware of how Windows works. Idle_Mind's is closest to what I'd do, though if the forms designer is familiar I'd go for a solution that basically just uses that - as such I present what I would do to solve the task you're faced with:
Have an app with one form (or make this form an autonomous one within another app, but for now maybe do it as a dedicated app for simplicity) - make a new Windows Forms project
Have a Timer (a Windows Forms timer, out of the toolbox, not a System.Threading timer) with an interval of 60000 and Enabled = true
Have a timer Tick event handler on your form (double click the timer in the tray under the form designer to attach an event handler) that queries the DB and finds if there are any messages
If there are new messages, adds them to a listbox or something, and calls this.Show() to show the form
Have an eventhandler attached to the FormClosing event so when the user clicks X, the form hides instead of closes:
private void MyForm_FormClosing(object sender, FormClosingEventArgs e)
{
if (e.CloseReason == CloseReason.UserClosing)
{
e.Cancel = true;
Hide();
}
}
Maybe have the FormClosing event clear the messages listbox. This way if the form opens and the user is on lunch, the messages will build up and build up, then they can read them and clear them by closing the form. Calling Show on an already-visible form does nothing, so the messages will just accumulate into the listbox if more messages come in and the form is already visible
Good quick rule of thumb; never use System.Threading Timer in a Windows Forms app. Use a timer out of the forms designer toolbox instead. Only use a threading timer if you're writing a service or Console app etc. For stability reasons, Windows controls absolutely must be accessed by the thread that originally created the control. Windows forms timer is aware of this and its Tick event can safely access the controls (a form is a control, showing it requires to access it) in a Forms app
You should call Invoke to execute your delegate on the thread that owns the control's underlying window handle.
Something like this should work:
timer = new System.Threading.Timer((s) => {
EL.CustomMessageBox l = new EL.CustomMessageBox();
l.Invoke((Action) () =>
{
l.ShowDialog();
});
}, null, TimeSpan.Zero, 60000);
Or even better, use this extension method:
public static void InvokeIfRequired(this Control c, MethodInvoker action)
{
if (c.InvokeRequired)
{
c.Invoke(action);
}
else
{
action();
}
}
And call it like this:
l.InvokeIfRequired(() => { l.ShowDialog(); });
Further information can be found at: https://learn.microsoft.com/en-us/dotnet/desktop/winforms/controls/how-to-make-thread-safe-calls-to-windows-forms-controls?view=netframeworkdesktop-4.8
First of all - I'm very low skilled programmer. I am building the foundation of a simple music app for my bachelor degree project. My question is regarding a internal clock method that is meant to increase an int value by 1 BPM times a minute.
I've created an internalClock class:
public class internalClock
{
// THIS METHOD WILL BE CALLED WHEN THE THREAD IS STARTED
public static void clockMethod()
{
int BPM = 135;
int clockTick = 1;
Form1 clockForm = new Form1();
// infinite loop
while (true)
{
if (clockTick == 8)
{
clockTick = 1;
}
else
{
clockTick++;
}
clockForm.metrobox.Text = clockTick.ToString();
Thread.Sleep(60 * 1000 / BPM);
}
}
}
This is how I managed to get an access to the RichTextBox itself:
public RichTextBox metrobox
{
get { return metroBox; }
set { metroBox = value; }
}
In the main 'Program.cs' I've written what's meant to start a separate thread to run the clockMethod until the program is closed:
// THREADING
// Create a thread
internalClock oClock = new internalClock();
Thread oClockThread = new Thread(new ThreadStart(internalClock.clockMethod));
// Start the internalClock thread
oClockThread.Start();
It's not updating the text in the RichTextBox. Also, if I call the clockMethod() without creating a separate thread for it - the application freezes. Sorry for my amateur question, I'm just getting started with C# (yeah.. my uni is useless). What am I doing wrong in my code?
So the above code has several problems, however I would encourage you to check out the Timer control that you can add to the form you want to do processing at a certain interval or in certain "ticks". MSDN Form Timer
With the timer you can remove that class you have and invoking a new thread, etc etc. I would read up on the Timer class in the given link and think about how you can re-work your application structure to fit that. The concepts for why that thread isn't working, etc, is frankly not that important for where you're at. I think you just need to focus for now on a tool that already does what you want it to do, which I believe is the Timer.
As a general note, you usually don't need to create a raw thread in .NET. As of .NET 4.0 you can access types called Tasks to perform multi-threaded logic and processing. If you find the need to do that later on, check that out. Task Type MSDN
I have a TextBox which tells the status of a running application (lets say notepad). If notepad is running Text of TextBox is running and not running for other case.
public string ProcessStatus
{
get
{
IsProcessRunning("Notepad.exe")
return "Running";
return "Not Running";
}
}
Now problem here is that view updates itself only once when it is launched. At that time if notepad is running it works fine. Now lets suppose I ran my application and notepad was not running then TextBox says not running. Now I launch notepad, now application is still saying not running as application has not updated the view. If I call notify of property changed event for the TextBox then it will say running. But I want here is that TextBox updates automatically.
The only solution what I am thinking right now is that I start a background process which keeps on updating ProcessStatus. But is this the right way? Is there any better way? Something like DirectoryWatcher for processes?
You could use a System.Windows.Threading.DispatcherTimer to check at regular intervals:
DispatcherTimer timer = new DispatcherTimer();
timer.Interval = TimeSpan.FromMilliseconds(10000); // checks every 10 seconds
timer.Tick += Timer_Tick;
timer.Start();
...
private void Timer_Tick(object sender, EventArgs e)
{
// do your checks here
textbox.Text = ProcessStatus;
}
You can find out more about the DispatcherTimer class from the DispatcherTimer Class page at MSDN.
Why not use the timer class to periodically run ProcessStatus, you can define the interval.
On this other question Can I Get Notified When Some Process Starts? there are two answers on how you can get notified if a process (e.g. Notepad.exe) starts. Both are neither ideal nor simple, I would probably stick to polling as Sheridan and NSmeef suggested.
We have an application that has a primary window, it can launch multiple other windows, in new browsers. We are using a silverlight application as a coordinating server in the primary window to close all windows that are part of the app, regardless of the way they are opened (we can't guarantee it was via window.open so don't always have a handle to the window in javascript).
On log out, we want to signal all the other windows to perform an auto-save, if necessary, then close down.
So all windows have a silverlight app, they coordinate using localmessagesenders. However, these are asynchronous:
private void ProcessAutosave()
{
foreach (string s in _windows)
{
SendMessage(s, "notify-logout");
}
// code here quoted later...
}
// sendasynch doesn't send until the method terminates, so have to do it in it's own function.
private void SendMessage(string to, string message)
{
var lms = new LocalMessageSender(to);
lms.SendCompleted += new EventHandler<SendCompletedEventArgs>(SenderSendCompleted);
lms.SendAsync(message);
}
Since the ProcessAutosave is called from a javascript onunload event which can't be cancelled, we need this to be synchronous and not complete before we have a response processed from each sub-window so the session state will still be valid etc.
In the SenderSendCompleted we remove items from _windows when they have said they're done.
So I added a loop on the end:
while(_windows.Count > 0) {
Thread.Sleep(1)
}
However, that never terminates, unless I put an iteration counter on it.
Am I the victim of a compiler optimisation meaning the changes in SenderSendCompleted do not affect that while loop, or, have I fundamentally misunderstood something? Or missed something obvious that's staring me in the face?
It sounds like a subtle verson of a race situation due to going sync/async. Couldn't the process in queston also receive notifications from the windows that they have received the message and are shutting down? Once all of the counter messages have been received, then the main app could shut down without the busy wait at the end(?).
I have found a way to work round. However, this does not really "solve" the problem generally, just in my case, which is also only supporting internet explorer.
function WindowCloseEventHandler()
{
var app = // get silverlight app handle...
app.doAutoSave();
var params = 'whatever you need';
var args = new Object();
args.hwnd = window;
window.showModalDialog('blocker.aspx',args,params);
}
function checkAutoSave()
{
var app = // get silverlight app handle...
return app.autosavecomplete();
}
Then in blocker.aspx we display a static "performing logout handlers" type message and do:
function timerTick()
{
if(window.dialogArguments.hwnd.checkAutoSave()) {
window.close();
} else {
setTimeout(timerTick, 500);
}
}
And start the timer on window load.
The child window's silverlight apps are notified to start an autosave, then they notify the parent when they are done. We then poll the parent's status from a modal dialog, which blocks the termination of the WindowCloseEventHandler() which we have wired up to the onclose event of the body.
It's hacky and horrible, but it means silverlight stays asynchronous and we're using a javascript timer so the javascript isn't loading the system.
Of course if the user closes the modal dialogue, there is a potential for issue.