Working with the RadDesktopAlert WinForms component by Telerik, I am wondering how can I perform an action when the user clicks anywhere on the alert window.
To put it blunt, the buttons suck, and it is much more natural (easier) for a user to just click anywhere in the window. I checked the basics, and there doesn't appear to be an event for "Click", nor does it appear to expose it's Hwnd or Handle.
The events that are available are
Closed
Closing
Disposed
Disposing
Opened
Opening
PropertyChanged
RadPropertyChanged
RadPropertyChanging
The problem with the buttons is the UI looks wacky when trying to right-align, and the "click" event doesn't fire unless you click well inside the button - TWICE. So using the Buttons are not an option. What I am looking for is a place to write code that runs when the user clicks anywhere on the RadDesktopAlert box.
Thanks in advance.
The RadDesktopAlert component, has a Popup property, which holds the actual popup element. You can use its Click event for the purpose:
AddHandler radDesktopAlert1.Popup.Click, AddressOf Popup_Click
Related
I realized while I was typing up this question what the problem might be and was then able to solve it. So, I have posted the question and then the answer in case it helps someone else.
I am using MS Access 2016. I have a Form_A that displays a menu of buttons--each button takes the user to a distinct form to perform whatever functions the user needs to perform. For example, one Form_A menu button could be [Add Clients] while another button could be [Add Staff], etc.
When the user first logs into the system, I use VBA code to do a number of "housecleaning" functions. Form_A and the buttons are visible, but I have made a Form_B that is a small dialog that shows the word "Working" with animated "..." while the VBA in Form_A does the housecleaning.
The problem that I cannot solve is that even though I have set Form_B's "Pop Up" property to "Yes" and its "Modal" property to "Yes", the user can still click buttons on the Form_A menu which then execute while Form_B is still doing its housecleaning.
I thought setting Form_B to modal should prevent button clicks on Form_A from getting registered.
More details:
In the Form_Load event, Form_A calls "housekeeping" code that resides in a Module. That module has a Public Sub called "RemakeTables." The RemakeTables code uses DoCmd.OpenForm "Form_B" to display the "Working" dialog.
The RemakeTables code calls several other Public subs. Between each call to the other Public subs, a DoEvents is called which allows for the "Working" dialog to animate the "..." (i.e., cycle between "Working", "Working.", "Working..", and "Working...").
My hunch is that the DoEvents is what is allowing clicks to get registered in Form_A.
How should I be doing this so that clicks cannot be registered while the Form_B "Working" dialog is showing but can still be animated?
As I was typing up the question, it occurred to me that the main problem was that the subs and functions I was calling during "housekeeping" used the DoEvents action to allow the Form_B "Working" dialog to update/animate. However, DoEvents also allows mouse clicks to register.
So, how to prevent the problem?
Include the "housekeeping" calls in the Form_Open event rather than the Form_Load event because the Form_Open event occurs first, before the Form_Load and before the form is displayed, so, there will not be any buttons visible to click if the "housekeeping" code is called in Form_Open.
Hope this helps someone else who might have had a similar problem.
I have a form that opens a modal pop up helper form to collect some data. When this modal pop up form closes, focus returns to the main form. I would like to trigger some activity when focus comes back to my main form.
The event model for the form does not trigger the Form_Activate or Form_GotFocus events when returning from a model popup as per Microsoft documentation.
These forms and all controls are completely unbound.
Is there a trick to knowing in code when focus returns to my form?
If both forms are placed in normal mode, Form_Activate does fire in the primary form when the helper form closes, but this does not meet my needs. I have not been able to find a similar event to trap this. I'm hoping someone has a workaround.
For clarity, the issue I ran into was I had the design time properties in the helper form set to act as a dialog - (pop up and modal as true). When I opened the form responding to the button click event on the main form, I did NOT include the acDialog option.
If you omit the WindowMode=acDialog setting the code operates asynchronously completing the code in the click event handler in full, NOT halting and waiting.
The acDialog option apparently forces the DoCmd.OpenForm command to run synchronously, halting code execution, then returning once the modal form has been closed.
Private Sub btnHelper_Click()
DoCmd.OpenForm "frmHelper", WindowMode:=acDialog
'Do stuff after frmHelper closes
End Sub
I'm building on top of code that a previous developer has left me, and he left something that intrigued me quite a bit.
Basically on his menus, he has a TextBox to take in user input and a button next to it to submit the value of the TextBox (for example if the user wanted to select option 1, he would input 1 into the TextBox and click the button). However, the user could also press the Enter key while focusing the TextBox, and it would be treated as the submit button was clicked.
Now this is simple enough to do, but when I check the VB code behind the menu, there's no TextBox_Keydown(...) Handles TextBox.Keydown function anywhere, only the button click event. How is he doing this? He has several menus that are similar and I can't figure out how.
A standard dialog box, if not told to act otherwise, enter does default command button and escape does cancel. In VB look at the properties Default for the command button.
I discovered how he was doing it. He basically mapped the AcceptButton and CancelButton properties of the entire Windows Form to various button functions.
Visual Studio with VB.net: If I create a copy of a button on the forms designer, the click event is added to the click event handler of the source button.
How do I change this behaviour ? I want the click event of the second button be wired to a totally new click handler code, not to the already existing one of the first button.
There are two ways to copy a button.
CTRL+C / CTRL+V (or same with right click menu). This will create a new button with a new event handler. Note that this new event handler is not created automatically, but will be created on button click in VS designer.
CTRL + drag a control into a new location. This will create a copy with the same event handler, i.e. add an event handler to already existing one. This is the behavior you are seeing.
I'd be interested to know the official reference about this behavior, found the above by experiment. I've used CTRL + drag copy method 95% of the time, and had the same question for quite a while. Fortunately, there is a quick fix for event wiring - read below.
If you used the wrong method, you can manually delete the wiring code (the second handles clause), then double-click the button in question to create new click event handler for it (not a big deal).
Working in SharePoint 2010, with SharePoint Designer 2010, I have a DispForm to which I've added a DVWP that displays a filtered view of another relative list. The DVWP has a 'New' link which opens the NewForm for that list in a modal dialog, using OpenPopUpPage (http://msdn.microsoft.com/en-us/library/ff410825.aspx).
After 5 - 12 seconds, the blinking cursor disappears from the first control and the focus switches to the 'Close' button. If the user was trying to type and happens to hit the Enter key when the focus switches to the 'Close' button, the background is no longer darkened and the 'Cancel' button no longer works. The form is still displayed on the screen, and the user can 'Save' but the modal never goes away until the page is refreshed.
If the user notices that the modal has lost focus and clicked back on the form, everything works as it should and all is well.
Observations:
When the control/modal loses focus, the 'Close' button does not trigger a 'focusin' event. But, $(document.activeElement).attr("value") displayed in the console shows that it's the active element.
Questions:
Why is the modal losing focus?
Does anyone have a Javascript/jQuery workaround to capture the event and set the focus back where it was?
Alternately, what if I lock the form and wait for this focus-change to complete, then unlock it and set the focus on the first field? Ideas?
You may be having a problem if the DispForm is also a dialog and you open the modal with your script. It sounds like you are getting a "layered" effect. My guess is that the script managing the dialog is interfering with the modal. Have you tried turning off the dialiogs for the list?
Just so I get some points on this site, the affliction was the asynchronous refresh of the first modal. It was taking the focus away from the layered modal.
Thanks JB for the answer!
I figured out the problem: the DVWP was using Auto-Refresh with the Async Update. This was running every 15 secs, taking the focus away from the modal, then not returning it to the last control.
So, we turned of the auto-refresh and used the callback from the modal close to trigger a click on the manual refresh button instead.