Vb Select Case

kegan5

Could you gimme a hand on this case part...
I'm trying to put in a case statement that takes 10% off if 2 users have enrolled and 15% if more than 3.


I had it working with an if statement but am not allowed to use if because it's messy apparently. I think the problem is you know where you say:

'Select Case int Enroll

I'm not sure where I'm supposed get intEnroll from as I have 4 different counters for each subject.

Does that make sense? The full code I have done so far is below

Thanks
Kegan5


_______________________________________
Option Explicit ' Explicitly decares variables
Dim mintNumBusinessClicks As Integer
Dim mintNumMathsClicks As Integer
Dim mintNumScienceClicks As Integer
Dim mintNumComputingClicks As Integer
Dim mstrTName As String
Dim mcurCost As Currency
Dim mcurCCost As Integer
Dim mintTotal As Integer
Dim mcurDiscount As Integer
Dim mcurDiscount2 As Integer
Dim intEnroll As Integer

Private Sub cmdCalculate_Click()
If mstrTName = txtName.Text Then
mcurCCost = mcurCCost + 100
If optYes.Value = True Then ' nested IF statement
mcurCost = mcurCost + 15
End If

Else
mcurCost = 0
mcurCCost = 0
End If
mstrTName = txtName.Text
mintTotal = mcurCCost + mcurCost
mcurDiscount = 0
mcurDiscount2 = 0


Select Case intEnroll
Case 0
Case Is = 2
mcurDiscount = 10
Case Is >= 2
mcurDiscount = 15
Case 1
Case Is = 2
mcurDiscount = 10
Case Is >= 2
mcurDiscount = 15
Case 2
Case Is = 2
mcurDiscount = 10
Case Is >= 2
mcurDiscount = 15
Case 3
Case Is = 2
mcurDiscount = 10
Case Is >= 2
mcurDiscount = 15


End Select


mcurDiscount2 = mintTotal * mcurDiscount / 100

lblTotal.Caption = "The mintTotal mcurCost of all your chosen courses is " & mintTotal
lblDiscount.Caption = "The Discount Awarded was : £" & mcurDiscount2
End Sub

Private Sub cmdConfirm_Click()
Dim Course As String
lblResult.Caption = "Name: " & txtName.Text & vbCrLf & "Address: " & txtAddress.Text & vbCrLf & "Phone Number: " & txtPhone.Text
Course = list.Text
lblCost.Caption = "Course Chosen: " & Course

If optYes.Value = True Then
lblPractical.Caption = "Practical Fee €15"
Else
If optNo.Value = True Then
lblPractical.Caption = "No Practical Option Chosen"
End If
End If
If cmbArea.ListIndex = 0 Then
lblPractical2.Caption = "Location: IT Carlow"
Else
If cmbArea.ListIndex = 1 Then
lblPractical2.Caption = "Location: Wexford It"
Else
Dim Other As String
Other = txtOther.Text
lblPractical2.Caption = "Location: " & Other
End If
End If
MsgBox ("Number Of People enrolled for Business: " & mintNumBusinessClicks & vbNewLine & "Number Of people enrolled for Science: " & mintNumScienceClicks & vbNewLine & "Number Of people enrolled for Maths: " & mintNumMathsClicks & vbNewLine & "Number of people enrolled for Computing" & mintNumComputingClicks)
End Sub

Private Sub cmdNext_Click()

optYes.Value = False
optNo.Value = False
lblCost.Caption = " "
lblPractical.Caption = " "
lblPractical2.Caption = " "
list.ListIndex = -1
End Sub


Private Sub Form_Load()
'Sets Values to the Variables
mintNumBusinessClicks = 0
mintNumScienceClicks = 0
mintNumMathsClicks = 0
mintNumComputingClicks = 0
End Sub


Private Sub itemCalculate_Click()
If mstrTName = txtName.Text Then
mcurCCost = mcurCCost + 100
If optYes.Value = True Then ' nested IF statement
mcurCost = mcurCost + 15
End If

Else
mcurCost = 0
mcurCCost = 0
End If
mstrTName = txtName.Text
mintTotal = mcurCCost + mcurCost
txtmintTotal.Caption = "The mintTotal Cost of all your chosen courses is " & mintTotal
End Sub

Private Sub itemConfirm_Click()
Dim Course As String
lblResult.Caption = "Name: " & txtName.Text & vbCrLf & "Address: " & txtAddress.Text & vbCrLf & "Phone Number: " & txtPhone.Text
Course = list.Text
lblmcurCost.Caption = "Course Chosen: " & Course

If optYes.Value = True Then
lblPractical.Caption = "Practical Fee €15"
Else
If optNo.Value = True Then
lblPractical.Caption = "No Practical Option Chosen"
End If
End If
If cmbArea.ListIndex = 0 Then
lblPractical2.Caption = "Location: IT Carlow"
Else
If cmbArea.ListIndex = 1 Then
lblPractical2.Caption = "Location: Wexford It"
Else
Dim Other As String
Other = txtOther.Text
lblPractical2.Caption = "Location: " & Other
End If
End If
intEnroll = MsgBox("Number Of People enrolled for Business: " & mintNumBusinessClicks & vbNewLine & "Number Of people enrolled for Science: " & mintNumScienceClicks & vbNewLine & "Number Of people enrolled for Maths: " & mintNumMathsClicks & vbNewLine & "Number of people enrolled for Computing: " & mintNumComputinClicks)
End Sub

Private Sub itemNext_Course_Click()
optYes.Value = False
optNo.Value = False
lblCost.Caption = " "
lblPractical.Caption = " "
lblPractical2.Caption = " "
list.ListIndex = -1
End Sub



Private Sub List_Click()
intEnroll = list.ListIndex
'adds 1 to each subject when user clicks on listbox option
Select Case list.ListIndex
Case 0 'Business
mintNumBusinessClicks = mintNumBusinessClicks + 1
Case 1 'Maths
mintNumMathsClicks = mintNumMathsClicks + 1
Case 2 'Science
mintNumScienceClicks = mintNumScienceClicks + 1
Case 3 'Computing
mintNumComputingClicks = mintNumComputingClicks + 1
End Select
End Sub

str8_away

Don't understand you case statement at all. It does not make much sense.

To your question:
Why don't you use four different discount variable for four different subject?

ie
'calculate discount rate for each subject
select case subject1
case < 2
discountRate1 = 0
case = 2
discountRate1 = 0.1
case > 2
discountRate1 = 0.15
end select

'calculate discount (saving) for each subject
discount1 = mintTotal1 * discount1

'repeat for other subjects

'calculate total discount
mintTotal = mintTotal1 + mintTotal2 + mintTotal3 + mintTotal4


'where subject = mintNumBusinessClicks or mintNumMathsClicks or mintNumScienceClicks or mintNumComputingClicks

hope this helps

ps
you don't say
If optYes.Value = True Then
you say
If optYes.Value Then

Think about it!!!
you are saying
If True = True then =>(which means) If True Then
If False = True then =>(which means) If False Then

bonkey

Originally posted by str8_away
ps
you don't say
If optYes.Value = True Then
you say
If optYes.Value Then

The more coding I do, the more I'm inclined to go against this traditional piece of wisdom. Why? Because I've seen too many people use non-boolean variables in there, which I feel is intrinsically a bad thing, and also I feel the more explicit version (the original) is more readable, while sacrificing virutally nothing in performance terms (if anything at all).

Remember, readability is more important than saving yourself a few characters typing, or a few bytes on your disk...

jc

str8_away

Call me old fashio if you like bonkey.
But I do not aggree what you said.

When a programmer uses none boolean variable in a "IF" statement VB will try to convert the variable into boolean if possible.
By saying "If optYes.Value = True Then" VB still try to convert the variable into Boolean then compare to TRUE and return Boolean result.
So the effect are the same when program uses none boolean variable it just one takes more processing power then the other.

As for readability, I think it is only a state of mind.
Do you type out "text1.text" every time you want to assign string to text box?

Regarding performance, I do agree it is very small, for one function. But if every programmer waste few clock pulse in each function then the performance of an over all system can be effected, when thousands of function can be called at any given time. This is also the reason why we don’t declare every thing as Variant.

kayos

Ahh wouldn't both options pretty much be the same when the code is compiled???

bonkey

Originally posted by str8_away
Call me old fashio if you like bonkey.
But I do not aggree what you said.

Theres nothing old-fashioned about disagreeing with me. Disagreeing with me seems to be all the rage these days

When a programmer uses none boolean variable in a "IF" statement VB will try to convert the variable into boolean if possible.

Yes, except for the funnies. For example, some DAO objects will return false if they are null, and will also return false if their value numerically equates to false (0 in VB). How many programmers are aware of this, and how many are aware of all of the similar quirks which can trip you up?

So the effect are the same when program uses none boolean variable it just one takes more processing power then the other.

To be honest, unless your code is inside the world's most performance-critical loop, you wont notice this, and if performance were really that important, you'd have to question the use of VB in the first place.

Your nice little analagy of "thousands of tiny inefficiencies compounding each other" is all well and good, but its simply not true. I use this "inefficient" approach in all of my code, and often have developed entire systems on my own using this approach. I can honesly say that I have never had a performance problem because of it, and that includes systems as early as VB3 running on a 486sx/16.

As for readability, I think it is only a state of mind.

Course it is. But do you know the state of mind if whoever will end up maintaining your code after you move onto something else?

Would you appreciate being given code you had problems reading? I know of no programmer who's code isnt clear to themselves (at least, then they write it), but will it be clear to whoever follows them? How many programmers actually think of this? Honestly?

Do you type out "text1.text" every time you want to assign string to text box?

Yes I do.

Do you know the default property of every single control shipped in Visual Basic? Will the person who has to maintain your code? Does the coding convention you use make it clear that you are dealing with the default property of an object, and not with just a variable? Will the person maintaining your code also be familiar with your coding convention? Do you define default properties on all your own "home-grown" COM objects for the same reason?

For these reasons - clarity and consistency - I go against the more performant "use the default-property" approach, and I explicitly state what property I'm using at any given point in time.

This is also the reason why we don’t declare every thing as Variant.

Actually I dont declare things as variant because its far more dangerous - you cannot guarantee what datatype visdual basic will interperet your value as all the time, and this can often have unexpected effects.

I'm aware of the memory and performance inefficiencies, but these are just added reasons why they are the work of the devil. The inherent doginess of Variants are why I avoid them.

Even when a variant may be the right thing to use, I will generally use type-specific variables and cast between them as needed. Its clearer, and there is no room for mistakes being made by the run-time deciding on the datatype based on the contents.

As for your performance argument....I dont buy into it at all. By far, the largest culprit in performance is not tiny things like what you are describing here, but rather inefficient design patterns, or poorly-thought-out / poorly implemented solutions. For example...I worked with a guy who had a recordset which was missing a field he needed as part of a change-request. His solution was for each record (while iterating through the original recordset) he ran a new query to retrieve the missing value. Me, I just deleted all his code afterwards, and added a single new field to the original query. This gained me about a 4-fold performance increase on the loop. Some other quick redesigns added another 3-fold improvement...in total giving about 12x improvement. Whether or not this guy used your IF structure or my IF structure is irrelevant in the face of such bad design.

ON the other hand, I have never (as stated above) seen a program run slowly because of explicitly typing the default property, or for making sure that I explicitly cast a value to the type I want, or including an '=true' or '=false' in an if clause.

The only places where performance may be critically important is when performaing an unavoidable loop over a large number of elements in a non-batch process. Once the design is optimised, and if performance is still an issue, I would consider implementing some additional optimisations - like using default properties, and some "hack" workarounds to avoid some of VBs intrinsic inefficiencies (like concatting strings - horribly inefficient if you do it the obvious way, highly efficient if you take a less obvious approach). I would then add comments around this critical code section to make the maintainer aware of what I had done, and why.

Dont get me wrong.....I'm not saying your approach is wrong. I'm just tired of trying to figure out "clever" code which I or someone else has written and which is ultimately not noticeably more or less efficient than clearer code. Same way I hate abbreviated variable names and other such programmer-laziness.

I'm offering an alternative, and the reason for why I see it as an alternative. Thats all it is - another option.

jc

p.s. Kayos - they should be the same, but up to V6.0, VBs compiler wasnt good enough to make that optimisation - same way it didnt handle "myTextbox" and "myTextbox.Text" in the same manner. Dont know whether the VB.Net compiler is any better...havent bothered reading much about it seeing as I'm mostly working with Java now.

Talliesin

p.s. Kayos - they should be the same, but up to V6.0, VBs compiler wasnt good enough to make that optimisation - same way it didnt handle "myTextbox" and "myTextbox.Text" in the same manner. Dont know whether the VB.Net compiler is any better...havent bothered reading much about it seeing as I'm mostly working with Java now

I can't say for a fact whether "If x Then" or "If x = True Then" will compile the same without experiments I can't be bothered with. I'd be extremely surprised if they differed.
However I do know that when compiled to machine code (and I'm pretty sure to P-Code) that "myTextbox" and "myTextbox.Text" will be treated exactly the same.
The treatment of "Text" as the default property is defined in the type library for the control. The compiler uses the type library at compile-time to compile in a call to a function pointed to by a pointer in the COM vTable. As such the compiled code is eactly the same if the Text property is explicitly defined or not. You can prove this is the case by implementing an interface with a default member, and then running it on a machine without the type library.
That said default properties are a hassle if they don't take parameters, as they lead to less readable code (the difference between Let myTextbox = herTextbox and Set myTextbox = herTextbox isn't something that is immediately obvious).

If myTextbox is defined as a Variant or Object rather than as a Textbox then the above doesn't apply, a call into a dispatch interface for the default property doesn't require you to query for the DispID (the DispID for default members is always 0) so it may even be faster in this case. On the otherhand the error-checking needed may make it slower.

kayos

I think the main thing about specifiing default properties is just of readablity and future proofing of code. Even MS recommend you use TextBox.Text = "bla" rather than TextBox = "bla" for the simple fact that default properties may change in furture revisions of objects (not really going to happen with a MS textbox control but more if you have your own custom controls).

Its all a case of ease readabilty and furture proofing. And readablity is something I really try to promote. I worked as a support programmer for a while and I spent more time commenting/formatting other developers code than fixing bugs!!! Even to this day if I am helping a developer the first thing I do is format their code correctly and add the nessary comments. Having a easy to read piece of code makes support and maintaince a lot easier.

kayos

Talliesin

Even MS recommend you use TextBox.Text = "bla" rather than TextBox = "bla" for the simple fact that default properties may change in furture revisions of objects (not really going to happen with a MS textbox control but more if you have your own custom controls).

Believe it or not but the MS textbox used to have Name as it's default property.

GUI

and i was gonna cane the guy for
posting help needed on vb :-)

The Corinthian

Originally posted by GUI_XP
and i was gonna cane the guy for
posting help needed on vb :-)

I don't think you should be allowed to breed.

str8_away

Just to prove that
do the following
Create a new project with nothing but a command botton on the form.

copy the following code in to form.

---

Option Explicit

Private Sub Command1_Click()
Dim temp As Boolean
Dim secStart As Currency, secTiming As Currency
Dim i As Long

temp = True
ProfileStart secStart
For i = 0 To 9999999
If temp = True Then
End If
Next i
ProfileStop secStart, secTiming
Debug.Print secTiming

ProfileStart secStart
For i = 0 To 9999999
If temp Then
End If
Next i
ProfileStop secStart, secTiming
Debug.Print secTiming
End Sub

Put the following code in a module

---

Option Explicit
Declare Function QueryPerformanceCounter Lib "KERNEL32" ( _
lpPerformanceCount As Currency) As Long

Declare Function QueryPerformanceFrequency Lib "KERNEL32" ( _
lpFrequency As Currency) As Long

Private secFreq As Currency

Sub ProfileStart(secStart As Currency)
If secFreq = 0 Then QueryPerformanceFrequency secFreq
QueryPerformanceCounter secStart
End Sub

Sub ProfileStop(secStart As Currency, secTiming As Currency)
QueryPerformanceCounter secTiming
If secFreq = 0 Then
secTiming = 0 ' Handle no high-resolution timer
Else
secTiming = (secTiming - secStart) / secFreq
End If
End Sub


Run the project and you will see my IF statement is 0.2 second faster

SO THERE ...

kayos

Actually while your way is quicker the difference you quote is only for when the project is in debug...

If you compile the code down the difference is in and around 0.001 or 0.002. I have even seen the results proving the if temp = true method resulting in faster times. The only way you can really tell would be to run the test a couple of thousand times and log all the times to a file and then read and average them .

kayos

bonkey

Originally posted by str8_away
Run the project and you will see my IF statement is 0.2 second faster

Yeah.

First off, test this properly by :

1) Building two apps which perform the operations, rather than one which performs one then the other.
2) Build both as executables, using multiple options taking the various compilation options (sometimes "smaller" produces faster code than the "faster" option!)
3) Reboot your pc. Run one .exe 100 to 1,000 times, and log the response times.
4) Repeat option 3 for each .exe you have built.
5) Calculate averages, as well as logging best and worst times for each.
6) Calculate the difference in performance as a percentage of the time taken for the loop.
7) Decide if the answer for 6 is *really* significant in the face of all that.

I'm guessing that at the end of the day, you will notice that the answer to 7 should be no. If you dont think so, then go back and read the point I made about optimising intensive loops, and the point about insignificant performance differences.

I think you'll find at that stage that you have exactly proved my argument.

jc

Talliesin

Premature optimization is the root of all evil.

-Tony Hoare

(Frequently attributed to Donald Knuth, but it appears he was quoting Hoare).