I have a flexgrid within a Multipage under Main_Window.MultiPage2.Value = 2 this flexgrid has 8000 rows and I don't want those to load unless this page is actually clicked on. The code I have does just that, but the problem is is that it loads every single time and not just once. Is there a way to make it load on the first change, and then that's it?
Private Sub MultiPage2_Change()
If Main_Window.MultiPage2.Value = 2 Then
Call form_segment_carrier_auto
End If
End Sub
in form_segment_carrier_auto is a module that populates the flexgrid.
If I understand you correctly, you could declare a Public Boolean variable, for example:
Public ChangedOnce As Boolean
This should be in some standard code module.
Then change your event handler to:
Private Sub MultiPage2_Change()
If ChangedOnce Then Exit Sub
ChangedOnce = True
If Main_Window.MultiPage2.Value = 2 Then
Call form_segment_carrier_auto
End If
End Sub
The event handler will still be called on multiple occasions if the event occurs on multiple occasions, but only the first call will do anything.
Related
This question is from one of my customers who is developing an excel web add-in, they would like to detect whether the event is trigger by end-user or trigger by the code.
They have registered a Worksheet.onChanged event handler.
They would like to ignore the onChanged event change that triggers by their code themselves. and focus on Processing the event handler should only be done when the user changed the values.
Scenario:
add-in listens to the sheetChange event. add-in user to enter values into the crosstabs, which the add-in will push to the server.
However, add-in API can also do some modification on the crosstabs, for example, the add-in can enable the user single click and drill down to get more data, their API logic will fetch data from the service and write to the crosstabs. however, the sheetChanged event will be triggered as well.
The solutions that the customer has been tried:
First try:
We tried to deregister the event handler before changing the values.
We then registered again after having the values changed.
This did not work as the deregistration is async and we were not able to await the deregistration.
Second try:
context.runtime.enableEvents = false
This is not possible as there are other events we are still interested in.
Current try:
We store the address of the changed range before changing the values.
In the onChanged handler, we compare the address.
If the same we do not do the logic.
After that, we delete the storage of the address again.
I also have tried to use a global flag and checking for that in the event handler, it doesn't work. here is my gist: https://gist.github.com/lumine2008/2b51d94d20cdca9ac9a0e97029dfd95c
Office.js doesn't provide such functionality yet.
Some workarounds, including a) context.runtime.enableEvents API, b) the global flag, or c) deregistering event before changing ranges and re-register event later, don't work cross-platform.
They will over-suppress events in some scenarios, which means some events triggered by user operations will be suppressed as well.
The most reliable way is your "current try"
Record the address of the to be changed range before changing the values.
In onChanged event handler, compare the event args with the address you recorded before. If it matches, clear the record and exit the event handler.
You can make a variable that chechs if the user is editing.
for example:
Private Sub Worksheet_Activate()
Static programChanging As Boolean
programChanging = False
End Sub
Private Sub Worksheet_Change(ByVal Target As Range)
If programChanging = False Then MsgBox("The User Is Changing")'*Do your code here*
End Sub
Private Sub Worksheet_SelectionChange(ByVal As Range)
programChanging = True
Range("A1").Value = "The Program Is Changing"
programChanging = False
End Sub
You can use the programChanging variable to check if the user is changing instead the if the program is changing but the principle stay the same.
~~Edit~~
You can also use one of the cells as the variable like:
Private Sub Worksheet_Change(ByVal Target As Range)
If Range("A1").Value = "False" Then MsgBox("The User Is Changing")'*Do your code here*
End Sub
Private Sub Worksheet_SelectionChange(ByVal As Range)
Range("A1").Value = "True"
Range("B5").Value = "The Program Is Changing"
Range("A1").Value = "False"
End Sub
I have data in a textbox (call it info) on a userform that I would like the user to be able to change so I set up a info_change() subroutine. Problems are:
(1) as I load initial data into info.text from VBA, the info_change() subroutine is called.
(2) when I go into the info field to change the value INSIDE the info field, it call the info_change() subroutine again and continues to call the routine until the last entry I put in info field = value in info field before changing in (seems recursive)
Any thoughts? Maybe instead of calling it info_change(), call it another procedural event?
Thanks, Marty
Easy example using _AfterUpdate event
Instead of reacting each time a single part of the info textbox got changed by the control's _Change event, it's more efficient to use the _AfterUpdate event pausing till you changed to another control (btw could be easily augmented by a CommandButton procedure).
In order to prevent unnecessary calls a comparison is made between old and current info text using a type definition in the code module's declaration head. Furthermore I added a boolean IsTest variable to this definition to allow a test display of changes made triggering some other stuff in code (see b).
Additional hint: there's no recursion, the Change event or AfterUpdate event are only firing as reaction to each single change or update, i.e. making no difference if triggered via Userform_Initialize settings or an eventual user input, however the condition check prevents the Init from getting active.
Declaration head of Userform code module
Option Explicit ' declaration head of code module
'User defined type
Private Type TThis
cnt As Long
oldTxt As String
IsTest As Boolean
End Type
Dim this As TThis
Private Sub UserForm_Initialize()
'[1]assign text to Info-Control
Me.TextBox1.Text = "bla bla"
'[2]remember text
this.oldTxt = Me.TextBox1.Text
'[3]optional choice of test modus
this.IsTest = True
If this.IsTest Then Debug.Print " #", "Change history", "(new) text" & vbNewLine; 0, Now, this.oldTxt
End Sub
Private Sub TextBox1_AfterUpdate()
'~~~~~~~~~~~~~~~
'~> Example call
'~~~~~~~~~~~~~~~
check Me.TextBox1
End Sub
Sub check(myTextbox As MSForms.TextBox)
' Purp.: compare current text with old text
If this.oldTxt <> myTextbox.Text Then
'a) optional test display
If this.IsTest Then this.cnt = this.cnt + 1: Debug.Print this.cnt, Now, myTextbox.Text
'b) do other stuff
' ...
'c) remember old text
this.oldTxt = myTextbox.Text
End If
End Sub
Hello wonderful VBA community,
I'm still really new to vba and am trying to learn a lot. Thank you in advance for looking through my code and my description of the issue I'm facing.
I have a button on a page that calls a new Userform.
CODE SNIPPET 1:
Sub btnShowDetails_Click()
Call frmShowDeets.ShowDeets
End Sub
... which calls the next bit of code in the 'frmShowDeets' UserForm:
CODE SNIPPET 2:
Public Sub ShowDeets()
Dim frm As frmShowDeets
Set frm = New frmShowDeets 'this line triggers the Userform_Initialize() event below
frm.Show
End Sub
... triggering:
CODE SNIPPET 3:
Private Sub UserForm_Initialize()
Dim comboBoxItem As Range
For Each comboBoxItem In ContactList.Range("tblContactList[CompanyName]")
'^refers to unique values in a named range
With Me.boxCompanySelection
.AddItem comboBoxItem.Value
End With
Next comboBoxItem
End Sub
So at this point, the form I want to display has values loaded in its one combobox for user selection. The user selects a company and the Combobox_Change event triggers other routines that pull information for that company.
CODE SNIPPET 4:
Public Sub boxCompanySelection_Change()
Call frmShowDeets.PullData
End Sub
Sub PullData()
Dim numCompanies As Long
numCompanies = ContactList.Range("B6").Value 'this holds a count of the rows in the named range
Dim FoundCell As Range
Set FoundCell = ContactList.Range("tblContactList[Company Name]").Find(What:=boxCompanySelection.Text, LookIn:=xlValues, LookAt:=xlWhole)
Dim CompanyRow As Long
CompanyRow = FoundCell.Row
With ContactList
'pull a bunch of the company's details
End With
End Sub
Here is where it gets weird... Once the form is shown and the user selects one of the combo box items, triggering the Combobox_Change event the code breaks because the 'What:=boxCompanySelection.Text' part of the Range().Find method reads as "" empty (even though Code Snippet 3 is meant to load in company names and Code Snippet 4 is only triggered when the user selects one of those company names from the combobox) and I shouldn't need to build something to handle 'not found' exceptions since the only possible values should be the ones pulled in from my named range.
From stepping through the code, I have determined that for some reason, Code Snippets 2 and 3 run TWICE before Snippet 4 is run. Does anyone know what about my code is causing this to happen? I'm thinking there's a disconnect between the form that is shown and loaded with combobox values and whatever Code Snippet 4 is reading data from.
What is weirder is that if I run the code starting from Code Snippet 2 (ignoring the button call in Code Snippet 1), the form works as intended and from what I can tell 2 and 3 are only run once.
The problem is probably something simple I'm overlooking but I just cannot figure out what it is. Thanks again!
You have to understand that a form is an object - exactly as any other class module, except a form happens to have a designer and a base class, so UserForm1 inherits the members of the UserForm class.
A form also has a default instance, and a lot of tutorials just happily skip over that very important but rather technical bit, which takes us exactly here on Stack Overflow, with a bug involving global state accidentally stored on the default instance.
Call frmShowDeets.ShowDeets
Assuming frmShowDeets is the name of the form class, and assuming this is the first reference to that form that gets to run, then the UserForm_Initialize handler of the default instance runs when the . dot operator executes and dereferences the object. Then the ShowDeets method runs.
Public Sub ShowDeets()
Dim frm As frmShowDeets
Set frm = New frmShowDeets 'this line triggers the Userform_Initialize() event below
frm.Show
End Sub
That line triggers UserForm_Initialize on the local instance named frm - which is an entirely separate object, of the same class. The Initialize handler runs whenever an instance of a class is, well, initialized, i.e. created. The Terminate handler runs when that instance is destroyed.
So ShowDeets is acting as some kind of "factory method" that creates & shows a new instance of the frmShowDeets class/form - in other words whatever happened on the default instance is irrelevant beyond that point: the object you're working with exists in the ShowDeets scope, is named frm, and gets destroyed as soon as it goes out of scope.
Remove the ShowDeets method altogether. Replace this:
Call frmShowDeets.ShowDeets
With this:
With New frmShowDeets
.Show
End With
Now the Initialize handler no longer runs on the default instance.
What you want, is to avoid using the default instance at all. Replace all frmShowDeets in the form's code-behind, with Me (see Understanding 'Me' (no flowers, no bees)), so that no state ever accidentally gets stored in the default instance.
Call frmShowDeets.PullData
Becomes simply:
Call Me.PullData
Or even:
PullData
Since Call is never required anywhere, and the Me qualifier is always implicit when you make a member call in a class module's code.
I read through several posts about similar problems and tried many solutions offered by this and other communities. I cannot tailor any of these to my specific needs.
I have an Excel workbook that generates a timesheet and a detailed job report based on the information provided in a userform.
The job report and the timesheet are exported to an Access table (or imported from said table to be edited or deleted).
I have a working version with repetitive code for validating the userform inputs.
There are eight inputs that must meet criteria.
i) must be a number
ii) must not be less than a minimum value
iii) must not be greater than a maximum value
I have a subroutine for each of these inputs that checks these criteria using BeforeUpdate, and calls another subroutine to make visible changes to the userform to alert the user of an invalid entry (alter the label color and caption, textbox or dropbox color, etc.).
Using AfterUpdate, I have a subroutine for each of the eight inputs that reverts these changes once a valid entry has been made.
This means I have 24 subroutines with basically the same code, where I feel there should only be three subroutines that can be used more generally.
Here is the code I have for these subroutines, as it is being used for one specific input:
Sub #1
Private Sub NumberOfTechs_BeforeUpdate(ByVal CAncel As MSForms.ReturnBoolean)
If Not IsNumeric(numberOfTechs) Then
Call NumberOfTechsInvalid("Must be a number!", numberOfTechsLabel, numberOfTechs)
CAncel = True
Else
If numberOfTechs < 1 Then
Call NumberOfTechsInvalid("Cannot be less than 1!", numberOfTechsLabel, numberOfTechs)
CAncel = True
ElseIf numberOfTechs > 6 Then
Call NumberOfTechsInvalid("Cannot exceed 6!", numberOfTechsLabel, numberOfTechs)
CAncel = True
End If
End If
End Sub
Sub #2
Private Sub NumberOfTechsInvalid(errorCaption As String, targetLabel As Object, targetControl As Object)
targetLabel.caption = errorCaption
targetLabel.ForeColor = rgbRed
targetControl.BackColor = rgbPink
targetControl.SelStart = 0
targetControl.SelLength = Len(targetControl)
End Sub
Sub # 3
Private Sub NumberOfTechs_AfterUpdate()
numberOfTechsLabel.ForeColor = Me.ForeColor
numberOfTechsLabel = "Number Of Techs"
numberOfTechs.BackColor = rgbWhite
' Call next subroutine
End Sub
I have a comment at the bottom of sub#3 that says "call next subroutine". This is where I am having difficulty.
I can pass the minimum and maximum values as variables, as well as specify the target control and label based on which user input triggers the call to sub#1.
The issue is passing the next subroutine as a string.
I tried placing these subroutines in their own module and using Application.Run. I tried using CallByName with these subs within the userform code.
I came across this similar issue and read the replies: Modeless form that still pauses code execution
I have been attempting to apply in my own situation the suggestion provided by David Zemens. In my situation, I cannot seem to find an approach that incorporates Mr. Zemen's suggestion without also utilizing a GoTo.
I am wondering if there is a better or more elegant solution.
Here is an outline of what I am doing:
I have a UserForm with a Command Button that begins the code execution that will perform several actions on multiple Excel workbooks. As such, there are a number of blocks of code and the successful completion of one block of code allows for the execution of the subsequent block of code.
At a certain point, depending on the situation, the code might require User input; in other situations, the needed data is obtainable from an Excel. If input is needed from the User, another UserForm is displayed.
The User may need to view several different Excel sheets before entering the input, so the UserForm is modeless. So the code comes to a stop until the User enters the needed input and clicks another Command Button.
It is at this point I am having trouble: how to resume the program flow. Is the only way to 'pick-up where it left-off' is by using a GoTo statement? Or is there some way to organize the modules so there is a single consistent program flow, defined in one spot and not duplicated from the point at which User input might be needed?
Here is my take on the problem . Hope I understood the problem correctly.
Assumptions:
There are two user forms.
UserForm1 with a button to start the processing.
UserForm2 with a button to supply intermediate input.
A sub inside a module to start/ launch UserForm1.
VBA Code (for the sub routine)
Sub LaunchUserForm1()
Dim frm As New UserForm1
'/ Launch the main userform.
frm.Show vbModeless
End Sub
VBA Code (for UserForm1)
Private Sub cmdStart_Click()
Dim i As Long
Dim linc As Long
Dim bCancel As Boolean
Dim frm As UserForm2
'/ Prints 1 to 5 plus the value returned from UserForm2.
For i = 1 To 5
If i = 2 Then
Set frm = New UserForm2
'/ Launch supplementary form.
frm.Show vbModeless
'<< This is just a PoC. If you have large number of inputs, better way will be
' to create another prop such as Waiting(Boolean Type) and then manipulate it as and when User
' supplies valid input. Then validate the same in While loop>>
'/ Wait till we get the value from UserForm2.
'/ Or the User Cancels the Form with out any input.
Do While linc < 1 And (linc < 1 And bCancel = False)
linc = frm.Prop1
bCancel = frm.Cancel
DoEvents
Loop
Set frm = Nothing
End If
Debug.Print i + linc
Next
MsgBox "User Form1's ops finished."
End Sub
VBA Code (for UserForm2)
Dim m_Cancel As Boolean
Dim m_prop1 As Long
Public Property Let Prop1(lVal As Long)
m_prop1 = lVal
End Property
Public Property Get Prop1() As Long
Prop1 = m_prop1
End Property
Public Property Let Cancel(bVal As Boolean)
m_Cancel = bVal
End Property
Public Property Get Cancel() As Boolean
Cancel = m_Cancel
End Property
Private Sub cmdlinc_Click()
'/Set the Property Value to 10
Me.Prop1 = 10
Me.Hide
End Sub
Private Sub UserForm_QueryClose(Cancel As Integer, CloseMode As Integer)
'/ Diasble X button
Me.Cancel = True
Me.Hide
Cancel = True
End Sub
OK so here are my thoughts.
You have a userform frmSelectUpdateSheet which you wish to use in order to allow the user to select the sheet, when the sheet can't be determined programmatically. The problem is that if you do .Show vbModeless (which allows the user to navigate the worksheet/s), then code continues to execute which either leads to errors or otherwise undesired output.
I think it's possible to adapt the method I described in the previous answer. However, that's out of the question here unless you're paying me to reverse engineer all of your code :P
Assuming you have a Worksheet object variable (or a string representing the sheet name, etc.) which needs to be assigned at this point (and that this variable is Public in scope), just use the CommandButton on the form to assign this based on the selected item in the frmSelectUpdateSheet list box.
This is probably a superior approach for a number of reasons (not the least of which is trying to avoid application redesign for this sort of fringe case), such as:
This keeps your form vbModal, and does prevent the user from inadvertently tampering with the worksheet during the process, etc.
Using this approach, the thread remains with the vbModal displayed frmSelectUpdateSheet, and you rely on the form's event procedures for control of process flow/code execution.
It should be easier (and hence, cheaper) to implement; whether you're doing it yourself or outsourcing it.
It should be easier (and hence, cheaper) to maintain.
NOW, on closer inspection, it looks like you're already doing this sort of approach with the cmdbtnSelect_Click event handler, which leads me to believe there's a related/follow-up problem:
The sheet names (in listbox) are not sufficient for user to identify the correct worksheet. So if the user needs the ability to "scroll" the sheet (e.g., to review data which does not fit in the window, etc.), then add some spinner buttons or other form controls to allow them to navigate the sheet.