I thought I had everything functioning correctly, but while on-site during deployment, I discovered that it’s not working as expected. I have a string input exposed to VBA that includes a Change event, but it seems to be ineffective. I added a temporary MsgBox for debugging purposes, but it’s not executing at all. Here is the relevant section of my FTView SE 8.2 code: ```vba Private Sub CanNumber_Change() Dim FiberType As String MsgBox ("test") ' Debugging message FiberType = Mid(CanNumber.Value, 6, 1) ' Extracts character from string Set oTag = MyGroup.Item("ERE_FIBER_TYPE") ' Accesses group item ' Sets the fiber type based on extracted character If FiberType = "C" Then oTag.Value = 0 ElseIf FiberType = "G" Then oTag.Value = 1 ElseIf FiberType = "M" Then oTag.Value = 2 ElseIf FiberType = "P" Then oTag.Value = 3 ElseIf FiberType = "T" Then oTag.Value = 4 ElseIf FiberType = "H" Then If Mid(CanNumber.Value, 6, 2) = "HH" Then oTag.Value = 6 Else oTag.Value = 5 End If Else MsgBox "Invalid Can Number!" ' Error message for invalid input End If End Sub ``` If anyone has insights into why the Change event seems to be unresponsive, or tips on properly handling string inputs in VBA, I would greatly appreciate your assistance!
I believe it would be beneficial to eliminate that nested IF statement for improved clarity and functionality.
Error Verification is Essential. Always implement error checking in your code. This practice allows you to log diagnostic messages, helping you identify the reasons why your VBA scripts may have ceased functioning properly.
I discovered that using FTView for triggering change events on string tags is only reliable about 80% of the time. In the past, during my attempts to get this functionality working, I recall that change events were primarily triggered by modifications to the .LEN field, though I could be mistaken. To overcome this inconsistency, I opted to concatenate all characters in the string into a DINT format, using the DINT tag to successfully initiate my change events. This approach has proven to be more dependable for my projects.
It sounds like you might be running into an issue with the Change event not firing because of how FTView SE handles events with string inputs. You could try checking if other events like `LostFocus` or `KeyUp` are being triggered, as they might offer a better way to capture changes if the input isn't directly triggering the Change event. Additionally, make sure that `CanNumber` is correctly initialized and accessible by that subroutine; sometimes scope issues can prevent the event from executing as expected. Good luck debugging!
✅ Work Order Management
✅ Asset Tracking
✅ Preventive Maintenance
✅ Inspection Report
We have received your information. We will share Schedule Demo details on your Mail Id.
Answer: - Control Properties: Check the properties of the control to ensure it supports the Change event. Not all controls are compatible with every event. - Scope and Visibility: Make sure the event is within the correct scope and accessible. The VBA environment may not detect it if the scope is incorrect. - Enable Events: Confirm that VBA event handling is enabled in your environment settings.
Answer: - Use Debugging Tools: Place breakpoints or use `Debug.Print` to track the flow of execution. Ensure the code reaches the Change event handler. - Simplify the Code: Temporarily simplify the event code to isolate issues. Start with a simple `MsgBox` or `Debug.Print` statement to see if it triggers. - Review Conditions: Ensure conditionals inside the event are not prematurely exiting or preventing execution.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.