הערה
הגישה לדף זה מחייבת הרשאה. באפשרותך לנסות להיכנס או לשנות מדריכי כתובות.
הגישה לדף זה מחייבת הרשאה. באפשרותך לנסות לשנות מדריכי כתובות.
Question
Monday, April 26, 2010 9:54 PM
Hi,
I have a combo box on a form.
I have a SelectedIndexChanged event, that displays a message box when the combo box has another item from it selected.
This works fine.
However when the form is loaded, I initially want to set the current drop down box item from the database, then AFTER I have set the current value, I want this event to work. Problem is from the get go when the form loads it asks me the question as its being changed from 'no data' to then be populated with a bunch of data and an item selected.
any ideas how to get around this?
Private Sub cboResStatus_SelectedIndexChanged(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles cboResStatus.SelectedIndexChanged
If cboResStatus.SelectedItem = "Cancelled" Then
Dim dlgCancel As DialogResult
dlgCancel = MessageBox.Show("Are you sure you want to cancel this reservation #" & ViewReservationID & " (" & txtSurname.Text & ") ?", "Reservation Cancellation", MessageBoxButtons.YesNo, MessageBoxIcon.Question)
If dlgCancel = DialogResult.Yes Then
DeleteRes(ViewReservationID)
'Lets add to the audit of the reservation who has cancelled this reservation.
AuditAdd(ViewReservationID, UserCode, "Reservation has been cancelled.")
MessageBox.Show("Cancelled Reservation Number: " & ViewReservationID & "", "Booking Information", MessageBoxButtons.OK, MessageBoxIcon.Information)
'Set the cancellation combo box to read only.
cboResStatus.Enabled = False
btnSave.Enabled = False
End If
End If
End Sub
All replies (18)
Monday, April 26, 2010 10:04 PM ✅Answered
One way that you can do this is to declare a boolean variable on the class level - maybe something like "formLoading = True". In the SelectedIndexChanged event, add a simple "If" statement to check for this. In other words:
If formLoading = False Then
...
End If
As the last line of your form's load event, set formLoading to False.
I hope that works for you. :)
Monday, April 26, 2010 10:12 PM
Worked perfect.
Monday, April 26, 2010 10:15 PM
Worked perfect.
Great :)
Monday, April 26, 2010 10:17 PM | 1 vote
No quite sure that I understand you but you can just Remove and Add the handler (sorry, I can't user the code formatter now):
Private Sub myForm_Loading ....
RemoveHandler myCombobox.SelectedIndexChanged, AddressOf myComboBox_SelectedIndexChanged
'do any other thing
'Lastly, add the handler again
AddHandler myComboBox.SelectedIndexChanged, AddressOf myComboBox_SelectedIndexChanged
Note: Replace myForm/myComboBox with the actual names of your controls and objects.
Only performance counts!
Tuesday, March 29, 2011 8:08 PM
Awsome idea, us VB developers keep forgetting that this is an option!
Sunday, August 21, 2016 7:51 PM
One could falsify and check ComboBox.Enabled as a flag to use in the SelectedIndexChanged event while making changes then set back to true when done. Such events will still fire however (should they?) but at least you can assure status of the Global 'ComboBox' Variable.
Sunday, August 21, 2016 9:23 PM | 1 vote
No quite sure that I understand you but you can just Remove and Add the handler (sorry, I can't user the code formatter now):
Private Sub myForm_Loading ....
RemoveHandler myCombobox.SelectedIndexChanged, AddressOf myComboBox_SelectedIndexChanged
'do any other thing
'Lastly, add the handler again
AddHandler myComboBox.SelectedIndexChanged, AddressOf myComboBox_SelectedIndexChanged
Note: Replace myForm/myComboBox with the actual names of your controls and objects.
Only performance counts!
It's better not to add the handler in the first place if you are going to remove it in the form load handler.
Just comment out the "Handles Combobox.SelectedIndexChanged" from the event handler and add it in as shown at the end of the form load handler.
Commenting it out, rather than removing it entirely, acts as a reminder as to what the method is for.
Sunday, August 21, 2016 9:30 PM
...and add it in as shown at the end of the form load handler.
Or better yet, as the first part of the form's .Shown event handler sub.
Some people succeed because they were destined to, but most people succeed because they were determined to.
Sunday, August 21, 2016 9:32 PM
...and add it in as shown at the end of the form load handler.
Or better yet, as the first part of the form's .Shown event handler sub.
Some people succeed because they were destined to, but most people succeed because they were determined to.
Why?
Sunday, August 21, 2016 9:35 PM
...and add it in as shown at the end of the form load handler.
Or better yet, as the first part of the form's .Shown event handler sub.
Some people succeed because they were destined to, but most people succeed because they were determined to.
Why?
Based on something from someone who was active back then -- who's since passed (or I'm pretty sure) -- John used to say and had even showed that if part of the .Load events included something with a TableAdapter's loading, that only after the table completely loaded was the .Shown event raised.
I don't "do" databases (and you know this) but that's my recollection and many seemed to agree so...
Some people succeed because they were destined to, but most people succeed because they were determined to.
Sunday, August 21, 2016 10:27 PM
John used to say and had even showed that if part of the .Load events included something with a TableAdapter's loading, that only after the table completely loaded was the .Shown event raised.
Well that is true but how is it relevant. If the form load handler called a TableAdapter method then the load event wouldn't complete until the TableAdapter method finished.
As an aside the domentation shows the order of events as:
- Load
- Activated
- Visible Changed
- Shown
- Paint
which is easily checked as being accurate - but it all seems a bit odd. e.g how can you active a form that's not visible; how can you say a form has been shown when it's not been painted......
Sunday, August 21, 2016 11:00 PM | 1 vote
Well that is true but how is it relevant. If the form load handler called a TableAdapter method then the load event wouldn't complete until the TableAdapter method finished.
The TableAdapter was an example. The form Shown event is designed to provide an event that marks the end of the Load event. It is generally preferred over the Load event because errors occurring in the load event are potentially problematic, as the user may be required to interact with a form that is not completely loaded. If there is no possibility of a requirement for user interaction (including no possibility of a run-time error) then there is little difference between a line of code at the end of the Load event and the same line of code at the start of the Shown event.
You should not take the names used for the various events as literal descriptions. They are labels that roughly describe the stages of the form loading. The actual meaning of each stage in the process is described in the documentation.
Monday, August 22, 2016 12:07 AM
The form Shown event is designed to provide an event that marks the end of the Load event.
Well the design hasn't worked very well as the Activated and VisibleChanged events fire first so it doesn't represent the end of the load event handler at all.
It is generally preferred over the Load event because errors occurring in the load event are potentially problematic, as the user may be required to interact with a form that is not completely loaded.
Surely if there are errors in the load event handler the right place to handle them is in the load event handler, before the user sees the form, not three events later.
If there is no possibility of a requirement for user interaction (including no possibility of a run-time error) then there is little difference between a line of code at the end of the Load event and the same line of code at the start of the Shown event.
Agreed - which was the reason for my previous post.
You should not take the names used for the various events as literal descriptions. They are labels that roughly describe the stages of the form loading. The actual meaning of each stage in the process is described in the documentation.
The documentation says the Shown event "Occurs whenever the form is first displayed."
Surely it can't be displayed until it is painted, which occurs later*
*
Monday, August 22, 2016 12:08 AM
Well that is true but how is it relevant...
You asked me why - I explained why.
Right or wrong, that's why I said what I did.
Some people succeed because they were destined to, but most people succeed because they were determined to.
Monday, August 22, 2016 12:32 AM
Well the design hasn't worked very well as the Activated and VisibleChanged events fire first so it doesn't represent the end of the load event handler at all.
So by the time that the form is loaded then it is also Activated and Visible. That sounds about right to me.
Surely if there are errors in the load event handler the right place to handle them is in the load event handler, before the user sees the form, not three events later.
No. The error should always be handled where it occurs, so if there is a possibility of an error in Load event handler code, then that code should be moved to a place where dealing with that error is more reliable.
Agreed - which was the reason for my previous post.
You have ignored the caveat.
The documentation says the Shown event "Occurs whenever the form is first displayed."
Surely it can't be displayed until it is painted, which occurs later
No. The exact quote is "The Shown event is only raised the first time a form is displayed". The comment is not related to any sequence in which the events occur - that sequence is clearly indicated elsewhere.
Monday, August 22, 2016 1:23 AM
So by the time that the form is loaded then it is also Activated and Visible. That sounds about right to me.
Not to me - it's not visible until it's been painted. But the Loaded, Activated and VisibleChanged events all occur before the Shown and Painted events.
Surely if there are errors in the load event handler the right place to handle them is in the load event handler, before the user sees the form, not three events later.
No. The error should always be handled where it occurs,
What!
The documentation says the Shown event "Occurs whenever the form is first displayed."
Surely it can't be displayed until it is painted, which occurs later
No. The exact quote is "The Shown event is only raised the first time a form is displayed".
"Occurs whenever the form is first displayed."
"The Shown event is only raised the first time a form is displayed"
There is actually no difference between those two statements.*
*
I'm bored with this. My first post was in reply to Sylva Okolieaboh; I'm not at all clear why you and Frank chose to get involved - you don't appear to have raised anything useful. If you want to have an argument then go and find someone else to argue with.
Monday, August 22, 2016 1:27 AM
I'm not at all clear why you and Frank chose to get involved - you don't appear to have raised anything useful. If you want to have an argument then go and find someone else to argue with.
Dave,
You are aware that this is more than six (6) years old ... right?
Some people succeed because they were destined to, but most people succeed because they were determined to.
Monday, August 22, 2016 2:31 AM
I'm bored with this. My first post was in reply to Sylva Okolieaboh; I'm not at all clear why you and Frank chose to get involved - you don't appear to have raised anything useful. If you want to have an argument then go and find someone else to argue with.
You can't hide inaccurate and incomplete explanations in a thread just because it is old. If you want to necropost you will be called on the misstatements.