I am trying to set permissions for my form fields (continuous form) and permissions need to be re-evaluated every time a different record gains focus/selection. Right now the only way I've found is to have an OnFocus event for each editable control, but there's gotta be a better way...
I've already tried MouseMove, OnClick, etc. but they don't seem to work when clicking/moving from a control in one record to the next without clicking over empty space first. Also MouseMove seems to have a limit to how frequently it responds.
I would also appreciate something equivalent to an "On Focus Changed" event, if "On Record Changed" is not possible.
Try OnCurrent, or maybe OnDirty, and can also try OnAfterUpdate.
I usually put stops in all of the candidate events when I'm not sure which one to use. There are differences, but running your application and seeing when the events fire can help you decide which one to use.
The event you are looking for is : Form_Current
Related
MSAccess VBA:
Assume, in an arbitrary form, the focus is set to MyControl on that form.
How to "unset" the focus without giving the focus to another control?
I'm lokking for a code like
MyControl.UnsetFocus
In your circumstance, you probably want to just set focus back to the parent form. This meets the conditions of unsetting focus without giving another control focus, and tabbing or clicking will activate the focus / tab-navigation again from that form.
Here's an example:
Forms![MyForm].SetFocus
Note that per the documentation for SetFocus, if you attempt to SetFocus to a Form with child controls that have Enabled set, this will cause focus to automatically bounce to the first eligible child control per the documentation.
Form.SetFocus method (Access) # Microsoft Docs
The option to give focus to the parent form does work as proposed by meklarian
Alternatively, I recently had to do something similar but I wanted to update a textbox value and simply go back to whatever had focus before. This is another case where something like an "unsetfocus" would be awesome, but unfortunately doesn't exist.
Should you need to do something like this, the following works well
Screen.PreviousControl.SetFocus
I am using simple event handler in the while loop.
I have value change event for the boolean button. There is some code that takes 3-4 seconds to execute.
The problem is I am not able to click anything on my Front panel during this period. Is it possible to allow the user to click on other controls when event handler is working on some case (as I understand the event handler is able to collect all events and process them ASAP)?
I fully agree with Mikhail N Zakharov's answer, but anyway your problem can be easily solved by just unchecking the checkbox named Lock panel until the case for this event complates
Please see screenshot below.
PS. Once again it is not the best practise to make event structure to work for 3-4 seconds.
I think you need to restructure your application to make it more responsive. LabVIEW best development practices suggest keeping event handler code as fast as possible. One of the ways to handle this would be to send a message into the queue on the change of this Boolean control and process the queue in a separate loop.
All controls offer some kind of event to indicate that the value has been modified. For example, when you enter a textbox and begin typing with each keystroke there is a TextChanged event. When opening a combobox and selecting a new item in the dropdown, you get a SelectedIndexChanged event.
The trouble is that in many cases the change events signal a series of changes that represent some interim, unfinished state. e.g. When a user is typing his zipcode there's no reason to lookup the city and state or even attempt to validate it until the user finishes typing. When the user has focus on the shipping method combo and presses the up/down keys to navigate through the combo values as he attempts to find the one he wants there is no reason to assume the shipping method has been specified and thus apply it to the invoice. It may make sense to wait until he exits the combobox after paging through the values to signal that a shipping method has been selected. We don't want to be bothered by a series of interim states.
In our shop, we implemented a Finalized event that is only triggered when the user starts making some manual change (as opposed to programmatic changes like setting the zipcode from the DB) and then later finishes up. This Finalized event had to be handled differently for different controls; I'm not aware of any .NET features that would make providing this easier.
The only idea I now have is to try to use something like Rx (Functional Reactive Programming) to accommodate this. Any idea for a simple .NET approach that would facilitate this?
For the zip code textbox, you can use the leave event(occurs when the textbox loses focus), or in the textchanged event you can use an if statement:
if ziptextbox.text.length = 5 then
'Hooray! do stuff here
end if
And you can also just use the leave event for the combobox
The Validating and Validated events work just fine; however, the names were misleading and so it never occurred to me that these were appropriate.
All credit to Hans Passant for his comment that solved this for me. (Hans, will redirect credit to you if you answer.)
I have a custom window to display various objects from the input tree. Once an object is checked on the input tree and displayed in the window, I subscribe to the object's "Changed" event. I am absolutely sure that I did not subscribe to the event more than once. The problem I'm seeing is when I make changes to the object, such as color, the event fires 3 times.
pseudocode:
- Draw a borehole in a custom window<br />
- borehole.Changed += borehole_Changed<br />
- Change the color of the borehole<br />
- See event fire 3 times (I just added debug prints)
Edit:
I have noticed that just opening the settings and clicking "ok" without changing anything causes the 3 events to be fired. So now I assume it actually has nothing to do with changing the color.
I have also tried checking the DomainObjectChangeEventArgs PropertyNames property, but that is always empty.
It looks like the Changed event is being phased out in favor of ColorInfo.ColorChanged, ImageInfo.ImageChanged, etc. In fact, the Changed event is not fired anymore as of 2011 for color changes. Turns out that there were other things underlying that caused the event to fire.
Anyways, to make a long story short, don't use the Changed event.
I can't confirm this behavior, I only get one event - can you please tell us which version you are using? And - are you changing the color via code or via the settings page?
In my case I got a single callback in both cases.
Thanks
I am getting one event also. I am using 2011.1 and the ColorChanged event from the ColorInfo for the Borehole.
In other cases I do see multiple events, but these happen when the data changed triggers changes to other Borehole related data. For example, changing the KB will cause lots of underlying calculations and result in multiple event triggers.
I want to take an action in an Excel workbook macro after a period of inactivity (hide/protect some worksheets). What is the best/simplest way to achieve this?
Í'm assuming I'll use Application.OnTime to periodically check if the user has been active. But what events should I handle to see if the user was "active" (i.e. has does something - anything - with the workbook)?
Clarification: I want to detect all activity, not just changes. I.e. including mouse clicks, selecting, copying, navigating with the keyboard, changing worksheets, ...
I'm assuming that when a UI event happens that represents user activity, I will set a variable thus:
LastActivityTime = Now
and the macro run by Application.OnTime will check this variable to see if the user has been active recently. Which events (other than SheetChange) would I need to handle to set this variable? I had kind of hoped there would be KeyUp and MouseUp events, these two would probably have been enough.
Update: I have implemented this by handling Workbook_SheetActivate, Workbook_SheetSelectionChange and Workbook_WindowActivate. Realistically this is probably enough.
I have implemented this by handling Workbook_SheetActivate, Workbook_SheetSelectionChange and Workbook_WindowActivate. Realistically this is probably enough.
I can only see two solutions -- either handle evary single event the Application object has or use GetLastInputInfo function.
One simple way is to compare the content of the workbook with that of the last time you check. I believe combining this with Application.OnTime will solve your concern.