AdvancedHMI Software
General Category => Tips & Tricks => Topic started by: dmroeder on November 05, 2013, 11:04:04 AM
-
I did an experiment a while back for fun and I learned something about using text boxes in code (or any object for that matter). The basic idea was to figure out what was in a password text box using brute force (one character at a time). The reason I was doing this was because my wife had a really crappy password and I wanted to see how long it would take a processor to take to get a match by brute force.
It's a really silly experiment I know, and probably isn't the way that the real world works but I learned something that I thought was valuable (and probably common knowledge to real programmers): Don't directly reference form objects in loops. Read their state in code and use that variable instead (or at least in loops). Here's what I mean:
Lets say the user is going to enter a single number and we wanted to use a loop to see when it is equal to 8:
'This way is slow
for i = 0 to 9
if textbox1.text = (i) then MessageBox.show("Success!")
next
'Faster
dim enteredValue as string = textbox1.text
for i = 0 to 9
if enteredValue = (i) then MessageBox.Show("Success!")
next
Now a loop that is 0 to 9 isn't really significant but if you had a loop that requires many more operations, it can add up. Here's an example. In my test program, I entered 1234 into my password box and used some loops to increment characters one at a time until I got to the value. 1234 took 16,273,901 operations before I got to the value of 1234, which was 37.8 seconds. In this example, I was comparing my incremented value directly to the text box (my first code example). If I change the code to read the value of my textbox and store it in a variable (my second code example), then use the variable to do the compare, the time is cut to 1.9 seconds.
-
This is a really good way to demonstrate properties versus variables. When I teach someone object oriented programming for the first time, most people initially struggle with what a property really is. They appear and act so much like a variable that we can get stuck on thinking it is. In reality, a property contains two special kinds of function calls, the getter and the setter.
When you retrieve a property value, it calls the getter and executes some code to retrieve the value. It is typically just a single line of code, but can be as much code as needed. When you set the property to a value, it calls the setter function. More commonly the setter has more code because it can validate and even perform an action on the object.
Here is a typical property declaration that "maps" the property to an internal variable in the class:
'* Internal private variable
Private m_Value As Single
'* Property declaration
Public Property Value() As Single
Get
Return m_Value
End Get
Set(ByVal value As Single)
If value <> m_Value Then
'* Limit the value within the Min-Max range
m_Value = Math.Max(Math.Min(value, 9999), -999)
'*Invalidate to force a screen refresh
Me.Invalidate()
End If
End Set
End Property
You can see the "getter" retrieves what is stored in the variable m_Value and simply returns the value. However, the "setter" has a bit more code. It limits the value between -999 and 9999, then puts it into the variable m_Value.
So this is why directly referencing a property can be in efficient, especially in a large loop.