The durandal messageBox is quite handy, however I don't see a way I can close it programatically (I may need to do this for example if the user hits the back button or any other scenario which fires canDeactivate()).
How can I programmatically close a messagebox?
As an alternative, an approach which would allow me to close all open dialogs (whether they were triggered via show() or showMessage()) would work just as well.
Actually, digging into the source code a bit made this pretty obvious. showMessage just uses show under the covers, so we can just use the system MessageBox constructor to take advantage of the canned functionality while still having a handle to the VM in case we need to close it later.
var vm = new dialog.MessageBox('message', 'title', ['option1', 'option2']);
dialog.show(vm);
//somewhere else - forcibly close the dialog
dialog.close(vm);
Related
I and my co-workers can't seem to agree on what the best practice should be when it comes to Vue and popups.
The question is as follows:
You are on the main window, you get the data from the backend using REST API and you notice an error. To fix it, you go to an edit popup and after hitting save what should happen?
Should you call the API from the popup?
Emit the changed data and let the main window call the API?
...
This is very interesting question but I think the truth depends on your whole architecture, implementation and approaches you use.
Say, if you worry about the "separation of concern" you wouldn't give a popup any access to API because its work is to show you some data as a popup, return data, and that's it.
On the other hand, how are you handling errors? What if an error occurs when user works in popup? Where do you show error?
Another question is the usability. For example, if error occurs when you save data, if it's done by the main window, you are going to:
Show the error message
Make user to click some button again to show the popup
Fix a problem and click the Save button in it.
But if you would access API right from popup you would avoid first 2 steps. Another concern is how you handle wrong data.
If you are still in the popup you easily can validate the data and cancel saving (or disable this button at all) but if it's done after the popup is closed it may be too late.
We have a huge application that runs through a mass of code for every click you do. In one specific case, where you have a specific control in plain sight (so that the events are firing) and you load some special data into it and then click on the new button the form loses some events, like the closing event (you cannot close the form anymore and stop points in debug mode are not triggered) and one validating of a ComboBox that is really needed for the program. The only thing you can do when you get this kind of error is to restart the application to get out of this subform. But I tested it for 2 days now and even when I activate all points in the 'Exception Settings' I don't get any exceptions. The form (and other controls) are not losing ALL events. The resize, for example, still works. Even a specifically called AddHandler is not firing. Can you iterate somehow through the EventHandlerList? Or is there any way to test WHERE the event dies? Somehow any ideas on how to debug such a problem?
Am using vb.net in asp.net to create my project. I use also a bootstrap modal to get data from client.
In the modal I have buttons and textboxes that get the data from user. there is a FINISH button that ends the process and closes the modal
the problem is that the other buttons are not supposed to close the modal, but make some calculations and processes. At one hand I need the postback in order to tiger the events of the buttons, And at the other hand the post back closes the modal, and i have to re-open it at the end of each process. This action makes the modal close and re-open after each click, and it is not Nice or Convenient
I thought that if I disable the postback of the buttons, and use the OnClientClick to catch the client click, this will work for me. But the Question is how can I make the OnClientClick Call a server side code (Sub)?
Any other Suggestions are welcome :)
OnClientClick is just that the CLIENT CLICK it doesn't translate into a server side method. Each ASP.Net server control has an OnClick event which is associated with a server based method, but that would give you the exact same scenario that you're dealing with now.
In this situation, I would have the secondary buttons (i.e. the ones that don't close the modal by behavior) use AJAX to send/receive data from the server (accessing an ASHX file or some other handler/WebAPI). This removes the entire postback situation entirely which sidesteps the issue.
I'm making a VB.net application. I have a dialog that pops up at some points. It is set as TopMost. The problem is, when it pops up, you can't move the main form. How can I make it so it shows and is usable while allowing the main form to continue to be usable?
It sounds like you're calling ShowDialog(), but the behaviour you describe sounds like you want to call Show() instead (of course, this'll mean that you will not get the DialogResult, nor will the calling code block, but this allows the parent window message loop to handle things like moving the window)
I'm having a weird issue with form painting in the Compact Framework. I have a login dialog that is basically a small form that is opened on top of another using ShowDialog. When a card is swiped, the login dialog is supposed to close, then some login tasks are performed and then the form behind it should be activated. The problem is that the form behind the login dialog is not being refreshed and so the login dialog will not be removed until after the form behind is refreshed by some user action. This is probably due to the heavy processing that goes on in the login tasks part, but I've not found a way to solve this.
Basically, I want a way to force the application to close the dialog and paint everything again, before performing the heavy login tasks. I've tried numerous refresh methods without any luck:
Form loginDialog = new Form();
DialogResult result = loginDialog.ShowDialog();
loginDialog.Dispose();
//I've tried everything at this point to get the form to refresh before performing
//login tasks
this.Refresh();
this.Invalidate();
Application.DoEvents();
PerformHeavyLoginTasks();
Does anyone know what could be going wrong? Thanks
Ok I figured this out. The problem was with a custom control on the background form that manually paints itself using rectangles and such. I think this is a compact framework bug since I called Refresh and Invalidate on that control as well and it should've repainted. I had to create a method that would call the control's OnPaint override directly since Invalidate and Refreshed were pretty much ignored.
The issue, I believe, is that you're not fully understanding what's going on system-wise here.
When your fore window (the Dialog) is dismissed, the background window (the Form) is given focu and tol to repaint the clipping region where the dialog was. This happens via a PostMessage call, which sends a Windows Message that has to be popped, translated and dispatched down in the bowels of the Application.Run call.
This is, by design, a fairly slow process as the UI should not be preempting things that are important.
If you are doing heavy processing immediately after that PostMessage happens, the processing of those windows messages can often be slowed, ending up with the UI appearing "locked" or drawing really slowly. This is exacerbated if the processing you're doing is on the same thread as the UI.
Why are your efforst not making things better?
Calling Refresh simply sends another message. That message now gets in line for processing, so it would actually make things worse.
Calling Invalidate does pretty much the same this as Refresh, just asynchronously. Again, it makes things worse.
DoEvents tells the message pump to pop, translate and dispatch a message. That dispatch still has to be processed on the UI thread, so noting is going to happen until the thread has time to do the work (i.e. after your processing)
So how do we "fix" this?
The first step is often to put the processing on a separate thread to allow the scheduler to round-robin tasks between the UI and processing threads, up to the default quantum. Thgis means that the processing can only starve the UI for a maximum of 100ms before some sort of drawing is allowed to occur (assuming equal thread priority).
new Thread(PerformHeavyLoginTasks)
{
IsBackground = true
}.Start();
You can go a step further and give the UI a "jump start" on the processing (of 10ms in this example):
new Thread(new ThreadStart(delegate
{
Thread.Sleep(10);
PerformHeavyLoginTasks();
}))
{
IsBackground = true
}.Start();
Of course this may mean you need to now handle the next "display" asynchrously if the UI you want to display is dependent on the processing result. There are plenty of online resources for async patterns, so I won't beat that dead horse here.