locked
Input text and output text. RRS feed

  • Question

  • What's the code for input and output text?


    Ex.

    I have two textboxes. Textbox1 and Textbox2.  I type in "1 2 3" in Textbox1.  I press a button and it converts the numbers to it's corresponding letter, like A B C. I need a code so that I can do that.



    Thanks in advance.



    Tuesday, July 29, 2008 11:46 PM

Answers

  • Instead of a load of if statements or case statements, you could do something like this:

        Private ConvertDictionary As Dictionary(Of CharString
     
        Private Sub Form1_Load(ByVal sender As System.ObjectByVal e As System.EventArgs) Handles MyBase.Load 
            ' 
            ' Create a new dictionary 
            ConvertDictionary = New Dictionary(Of CharString
            ' 
            ' Fill our dictionary with conversion characters 
            ConvertDictionary.Item("A"c) = "1" 
            ConvertDictionary.Item("B"c) = "2" 
            ConvertDictionary.Item("C"c) = "3" 
            ConvertDictionary.Item("D"c) = "4" 
            ConvertDictionary.Item("E"c) = "blah" 
            ' 
            ' etc. 
            ' 
        End Sub 
     
        Public Function convert(ByVal this As StringAs String 
            If this Is Nothing Then Return String.Empty 
            ' Optionally, make it uppercase 
            this = this.ToUpper 
            ' Convert to a character array 
            Dim chars() As Char = this.ToCharArray 
            ' Result goes in the stringbuilder 
            Dim result As New System.Text.StringBuilder 
            ' loop around each character 
            For Each c As Char In chars 
                If ConvertDictionary.ContainsKey(c) Then 
                    ' Append this to our result 
                    result.Append(ConvertDictionary.Item(c)) 
                End If 
            Next 
            ' Return the converted string 
            Return result.ToString 
        End Function 
     
    You create a dictionary of 'conversions': all valid characters are the 'key' in the dictionary, and what it converts to is the 'value' in the dictionary.

    Your 'convert' function will then rip through the characters in your passed string and create a string with each character replaced by the appropriate value.

    Stephen J Whiteley
    • Marked as answer by NolanLi Wednesday, July 30, 2008 5:27 PM
    Wednesday, July 30, 2008 1:21 PM
    Moderator

All replies

  • Ok I'll do this a bit long windedly than I normally would for the sake of clarity.

    Public
    Class Form1
    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
    Dim x As String, y As String, c As String
    TextBox2.Text = "" 'Clear 2nd text box
    x = TextBox1.Text 'Get string from 1st text box
    y = "" 'Clear final string which we will use for final output
    c = "" 'Clear string to hold each character
    For i = 1 To Len(x)
        c = Mid(x, i, 1)
    'Get current characters
        
    If c <> " " Then 'Only modify none spaces - note the space - chr$(32) might be better for u
            
    c = Chr(Asc(c) + 16) 'Convert from a number to a upper case letter
            
    'c = Chr(Asc(c) + 48) 'Convert from a number to a lower case letter
            
    'Note: we could use ucase or lcase statements to alter the case itead of hardcoding numbers
            
    y = y & c 'Append to the string we're building for final output
    Else
        
    y = y & c 'Just add the space 
        'Note the use of & for concatenating strings - we could use + but using & is less ambiguous
    End If
    Next i
    TextBox2.Text = y
    'Output final string
    End Sub

    Private Sub btnExit_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnExit.Click
    End
    End Sub
    End
    Class

    • Edited by bigamee Wednesday, July 30, 2008 12:37 AM Added a REM
    • Proposed as answer by Shariq Ayaz Thursday, September 24, 2009 9:05 PM
    Wednesday, July 30, 2008 12:27 AM
  • in the lines:

            c = Chr(Asc(c) + 16) 'Convert from a number to a upper case letter
            
    'c = Chr(Asc(c) + 48) 'Convert from a number to a lower case letter

    Just rem out the line you don't need and unrem the one you want.

    or you could follow:

            c = Chr(Asc(c) + 16) 'Convert from a number to a upper case letter
    with
            c=lcase(c)

    There are umpteen ways to do the same thing as this code lol Experiment and use whatever suits you best.
    Allan
    • Proposed as answer by Shariq Ayaz Thursday, September 24, 2009 9:05 PM
    Wednesday, July 30, 2008 12:43 AM
  • Thanks for your help, but I need something more customizeable.

    Something where I can edit what the output is.

    The only things going into the "input" box, (Textbox1) are letters. Ex. If I put in "A", it'll give me an output of something like ®

    • Edited by NolanLi Wednesday, July 30, 2008 1:10 AM Edited
    Wednesday, July 30, 2008 12:49 AM
  • Ok since I have NO idea what you need I'll talk in just general terms.

    Using x = mid(string,pos,1) we can get each individual letter from a string (which will then be stored in x)

    ASC(x) will give as a ASCII code for the letter, e.g. space = 32, 0=48, A=65, a= 97, etc.

    using that value we can do whatever we like to it to give is what we want.

    We can set up an array for conversions as in say:

     

    dim array(256) as string

    array(0)="Fred"
    array(1)="John"
    array(2)="X15"

    or whatever.

    then ASC(x)-97 could be applied so that typing in:

    a b c

    would could result in

    array(0) & array(1) & array(2) to give:

    "Fred John X15"

    see???

    Knowledge of basic string handling, ASCII codes, and functions like ASC, CHR$, etc. as well as variables and arrays and how to use them are essential to knowing how to program in BASIC.

    Once you have the basic principles under your belt, you can do pretty much anything what you want to do with strings, ok?

    Purely for example, say you want to write an assembler that has fixed instruction set - like say a Z80A assembler/disassembler.
    You could set an array to help like:

    Dim mnenomics() as string

    mnenomics(0)="NOP 00"
    ...
    mnenomics(62)="LD A,0 3E XX"
    ...
    mnenomics(201)="RET C9"
    ...
    etc. etc.

    Note that  the observant may see that here the array index is the opcode.
    Writing an assembler/disassembler involves a LOT more work than just creating an array of mnenomics and opcodes - I know cos I wrote a couple of them back in the days of the Z80A and 6502 microprocessors. But string arrays are necessary to help in quickly converting mnenomics to opcodes and vice-versa. More complex microprocessors e.g. for x86 assemblers and disassemblers would actually build the mnenomics and opcodes from register bit patterns applied to a core set of mnenomics and use an army of small arrays  rather than rather than a huge array holding all the possibilities - 
    BUT (quickly getting back to the point) the basic principles of string handling etc. would still apply.
    Allan

    Note that there would be little point to even thinking of writing an x86/x87 assembler/disassembler in BASIC as direct access to mmemory/ports is not allowed in Windows and/or VB - and it' be so complex and slow (methinks) as to be unusable. Of course you could write one that's outputs to a text file say just for fun lol That's why so don't see the huge range of assemblers/disassemblers on the X86/Windows platform that you saw on the 8-bit micros or see in Linux etc.

    • Proposed as answer by Shariq Ayaz Thursday, September 24, 2009 9:05 PM
    Wednesday, July 30, 2008 1:41 AM
  • NolanLi said:

    What's the code for input and output text?


    Ex.

    I have two textboxes. Textbox1 and Textbox2.  I type in "1 2 3" in Textbox1.  I press a button and it converts the numbers to it's corresponding letter, like A B C. I need a code so that I can do that.



    Thanks in advance.





    I'm not sure that I understand your question either, but I'll give this a shot.

    For the following code I simply dropped two Textboxes and one Button onto my form.  I did not change the default names.  After placing the three controls, I double clicked on Button1 to open the code window and create a framework for the Button_click routine.

    The resulting code (in it's entirety) is included below.

    Public Class Form1  
        Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click  
            TextBox2.Text = Convert(TextBox1.Text)  
        End Sub  
        Private Function Convert(ByVal text As String) As String  
            ' Now just take the string in "text," do whatever  
            '   needs to be done to convert it, and then Return  
            '   it as a string.  
            ' Here I just do a simple conversion to uppercase,  
            '   but you have the string you want to convert in  
            '   "text" and all you have to do is "Return" the  
            '   result.  
            Return text.ToUpper  
        End Function  
    End Class 

    After the code is entered and you run the program, any text in TextBox1 is converted to uppercase and written to TextBox2.

    Instead of using input and output, we access the text property of the objects.

    I have a feeling that your question might be more complex than I realize, so if I'm way off the mark here I appologize. 
    Wednesday, July 30, 2008 3:19 AM
  • Thanks REDMX5. That's partly what I wanted.

    Would you be able to convert by "If"s?

    Ex. 

    If textbox1.text = ("A") then textbox2.text = ("Microsoft")  
    • Edited by NolanLi Wednesday, July 30, 2008 6:27 AM woops
    Wednesday, July 30, 2008 6:26 AM
  • Instead of a load of if statements or case statements, you could do something like this:

        Private ConvertDictionary As Dictionary(Of CharString
     
        Private Sub Form1_Load(ByVal sender As System.ObjectByVal e As System.EventArgs) Handles MyBase.Load 
            ' 
            ' Create a new dictionary 
            ConvertDictionary = New Dictionary(Of CharString
            ' 
            ' Fill our dictionary with conversion characters 
            ConvertDictionary.Item("A"c) = "1" 
            ConvertDictionary.Item("B"c) = "2" 
            ConvertDictionary.Item("C"c) = "3" 
            ConvertDictionary.Item("D"c) = "4" 
            ConvertDictionary.Item("E"c) = "blah" 
            ' 
            ' etc. 
            ' 
        End Sub 
     
        Public Function convert(ByVal this As StringAs String 
            If this Is Nothing Then Return String.Empty 
            ' Optionally, make it uppercase 
            this = this.ToUpper 
            ' Convert to a character array 
            Dim chars() As Char = this.ToCharArray 
            ' Result goes in the stringbuilder 
            Dim result As New System.Text.StringBuilder 
            ' loop around each character 
            For Each c As Char In chars 
                If ConvertDictionary.ContainsKey(c) Then 
                    ' Append this to our result 
                    result.Append(ConvertDictionary.Item(c)) 
                End If 
            Next 
            ' Return the converted string 
            Return result.ToString 
        End Function 
     
    You create a dictionary of 'conversions': all valid characters are the 'key' in the dictionary, and what it converts to is the 'value' in the dictionary.

    Your 'convert' function will then rip through the characters in your passed string and create a string with each character replaced by the appropriate value.

    Stephen J Whiteley
    • Marked as answer by NolanLi Wednesday, July 30, 2008 5:27 PM
    Wednesday, July 30, 2008 1:21 PM
    Moderator
  • Thank you! That is exactly what I needed. I'm terribly new to Visual Basic, so kudos to everyone that helped.
    Wednesday, July 30, 2008 5:27 PM
  • Stephen used a Dictionary object, which is probably the most appropriate "VB way" of doing character conversion, but as an alternative you might consider using character array as a "translation table."  If you have to handle the entire ASCII character set, the array dimension would run from 0 to 255, or you could use a subset of that range if you only need to convert a subset of the character set.  The array would contain the character you want to generate for each input character, in a location defined by the input characters ASCII code.  For example, since "A" is represented by the number 65 (decimal), then we'd set TranslationArray(65) equal to the character that we want to use in the output when we see an A in the input.  In psuedo code we might initialize our translation array this way:

    TranslationArray(65) = "X"        '  The letter "A" will be converted to "X."
    TranslationArray(66) = "Q"        '  The letter "B" will be converted to "Q."
                    .
                    .
                    .

    Once the translation table is populated you can then use it to translate the characters as follows:

    OutputCharacter = TranslationArray(Asc(InputCharacter))

    That line converts the "InputCharacter" into an ASCII code that indexes into the "TranslationArray" to find the replacement character.

    The "translation array" is actually the simplest form of a technique known as "hashing."  A key word or symbol is converted to a number that indexes directly into an array to get the desired output.  The advantage of a Dictionary is that the code is (arguably) easier to read.  The only advantage to simple hashing is that it doesn't use an object and is pretty much language independent (it's pretty common in assembly language programming).

    Stephen, I don't want to hijack the thread, but do you think it's "bad form" to use something like a "translation array" when we could do the same thing with a VB object?  I predate objects (lol, meaning that I've was writing programs long before OOP) so code to index into an array to find a result seems "highly readable" to me, but I am concerned that my background is distorting my perspective.  To my "eye," in the code here, it's a wash, but I'm wondering if using the Dictionary object is better or not ("better" in terms of readability).  Have we reached the point where using the code for a character to index into an array is going to be seen as obtuse?
    (I don't what to start another discussion of programming style, but would just like to know your opinion.)

    • Edited by REDMX5 Wednesday, July 30, 2008 7:59 PM clarification
    Wednesday, July 30, 2008 7:57 PM
  • Thanks Red for explaining what I was so clumsily trying to explain. Arrays would be my first instinct too - I would (not at this stage anyway) have even thought of a dictionary object such as Stephen used (and which I'm very interested in) - thanks Stephen :)
    Red also gave a nice and concise description of hashing :) - again an old tried and tested technique that was/is the bread and butter of cryptology.

    Whatever method is used - the key point is that a user types something "A BC " or "1 2 3 " or whatever given an a sequence of ASCII values which are acted on to provide a different set of values (the 'translation') - which is kinda why I rambled on about assembly (could be any language).

    For example:

    Traditional BASIC's:
     10 PRINT "This is a message"

    or VBs msgBox("This is a message")

    or PASCAL's WriteLn("This is a message"")

    or C's printf "This is a message") or C++'s cout << "This is a message"

    or assemblies:

    DB "This is a message"
    .....
    MOV EAX, DB 'Or whatever instruction means point to string start
    CALL OSoutput
    ....

    All these statements are all basically the same - they each read a sequence of bytes (ASCII values) which get processed and output - possibly with conversions on the way.
    Like many such 'simple' tasks in programming, there are an enormous number of ways/means to achieve the same end - and the techniques are the same with a very wide variety of applications in this case - be it an English to Japanese converter program, an assembler, a program compiler or interpreter (whether it's C or VB or Forth or a macro in Word or whatever.
    What I am trying to say is a) The task is simple - take a value, maybe do some conversion, output the value (or newly converted value). That's also how VB was written - and works when executing your program. So in theory, once yiou done that basic task for reading a sequence of values and converting and outputting alternative values - you could build on it and write your own VB or language. In practice, nowadays, it would not be sooo easy - since you'd need special (and reserved) Operating System priviledges - but you could always do a kind of VB.Net for DOS - though it would have to be called something else to VB and merely be VB.Net compatible to some extent to avoid legal action from MS. Also you'd encounter lots of other problems - like lack of memory in DOS, and would have to maybe write an equivalent to Windows GUI - which could be faked a little by using DOS' line drawing characters.
    b) There is very LITTLE else to programming (you have to do assembly language to really appreciate that ALL computers do is just that - take a value from memory (a port is just another kind of memory), modify the value somehow, put the value somewhere else. That's it - full stop at the fundamental level. Sounds easy - and it often is - the real trick (and art and heart of programming) is knowing what to move, from where, what to do to it, and where to put it. There you go - teach yourself fundamental programing in a paragraph :)
    Allan

    Wednesday, July 30, 2008 9:54 PM
  • Here's a real, working, code snippet that does the task as I understand it, using the method I described earlier.  Old guys like Allan and myself tend to think of this kind of approach *first*, because it's so simple, but I'm not at all sure that the code is as easy for others to read as is the code written using the Dictionary object.  In any event, IF the way this code works isn't obtuse, then it's a very direct way to do the kind of translation you're doing here.  There are only eight lines of code that actually do anything, but if it's not "intuitively obvious" how the code works, then I'd advise against using it.

    Public Class Form1  
        ' Create a "translation array" to define the character by character replacements.  
        ' The following comment is here to help us build the translation array.  
        ' Pattern for string:   ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz  
        Dim TranslationArray = "zZyYxXABCcabFEDdefHiGgiHlk012345JKLjMNOmnopqrPQRStusTUVvwW".ToCharArray  
        Private Sub Button1_Click(ByVal sender As System.ObjectByVal e As System.EventArgs) Handles Button1.Click  
            Dim index As Integer 
            TextBox2.Text = "" 
            For Each character In TextBox1.Text  
                If character >= "A" And character <= "z" Then 
                    ' The next line of code uses the ASCII code of the character to  
                    '   index into the TranslationArray and return the translated character.  
                    ' We subtract Asc("A") from the ASCII value because our translation array  
                    '   starts at zero rather than 65 (Asc("A") equals 65 decimal).  
                    index = Asc(character) - Asc("A")  
                    TextBox2.Text = TextBox2.Text & TranslationArray(index)  
                Else 
                    TextBox2.Text = TextBox2.Text & character  
                End If 
            Next 
        End Sub 
    End Class 
     

    Change the TranslationArray string in the Dim statement to alter the translation scheme.

    To run the code, create a forms project, drop two TextBoxes and one button onto the form, double click the button, and replace all the code that appears in the code window with the code above.  Then run the program, type some text into TextBox1, and click the Button.
    Wednesday, July 30, 2008 11:48 PM
  • Thanks Red, but I need something like Stephen's because when I use the conversion, A usually converts to 2 words. 

    BUT

    I am curious of how you would use "Hashing". It looks pretty simple. Can you give me an example of how you would use it?
    Thursday, July 31, 2008 4:14 AM
  • NolanLi said:

    Thanks Red, but I need something like Stephen's because when I use the conversion, A usually converts to 2 words. 

    BUT

    I am curious of how you would use "Hashing". It looks pretty simple. Can you give me an example of how you would use it?

    Hashing can be simple, but it can also be very complex.  There are probably objects or classes that handle such things for us, but in "special cases" hashing can be a pretty elegant solution without getting complex.  I don't want to try to give a desertation on hashing, but a little terminology will help put it in a proper perspective.

    A "Hash Table" is just a table (or array) that is accessed using some kind of key that is used to calculate an index into the array.  A "Key" is just something symbolic that can be converted into some kind of index into a Hash Table.  Alphanumeric data, taken one character at a time, is used as the key, we have a special case, because we have a small set of symbols and they can be directly converted into a sequence of numbers.  If we dimension our Hash Table to hold 256 values, we can have an entry for every possible 7 or 8 bit character (aka symbol) we encounter.  This special situation lets us use what is known as a "densely populated hashing table."  We know that every symbol will produce a unique index (its numeric representation) and that the unique index will point to the proper place in our table.

    I'll discuss more complex and common situations later, but let's look at the code I posed earlier.

     Dim TranslationArray = "zZyYxXABCcabFEDdefHiGgiHlk012345JKLjMNOmnopqrPQRStusTUVvwW".ToCharArray

    This statement creates an array of characters that we can use as a Hash Table, because it has one entry for every possible character between "A" and "z," and that's all we're going to translate.  In this case we don't care about letters before "A" or after "z".  The string is just arbitrary, but we could do something cool with it.  Try substituting the string ...

    "AbcdEfghIjklmnOpqrstUvwxYz[\]^_`AbcdEfghIjklmnOpqrstUvwxyz"

    Notice the structure of the string.  All the vowels are in uppercase, while everything else is in lower case.  Y is in upper case the first time through, and lower case the second time through.  This string will produce an array that will "translate" all the vowels in the source string to upper case, and all the other letters, except Y, to lower case.  The case of the letter Y will not be changed.  In other words, this is a funny translation that mirrors the viowels, A, E, I, O, U, and *sometimes* Y.  ;-)

    Now all we do is take a character and use convert it to a pointer into the array.  In the code above, this happens in the line that calculates a value for the variable "index."

                   index = Asc(character) - Asc("A")  

    The Asc() function returns the value that represents the character that is passed.  We want the character "A" to take us to the first entry in our hash table (beause that's where the character that is to replace "A" is stored).   If we subtract the representation value of "A" from our character, and the character IS "A", the result is zero.  Woohoo, that's the right index.  If the character is "B" we get 1 when we do the subtraction, and again, we have an index that points to the replacement character.  When we get to "M" the subreaction produces the number 12, which, as before, takes us directly to the replacement for "M."  Whaever the character we have, as long as it is between "A" and "z", it will map to the entry in our array that contains the replacement character.

    Hashing is really just the process of converting a key or symbol into an index.

    It gets more complex when the symbols are more comples and/or discontiguous.  The classic example is the symbol table used by an assembler (an old school assembler ;-)).  Symbols might be composed of from one, to six or eight characters, and the characters might appear in almost any combination.  Each symbol likely resolves to an address or some other value, and the assembler is going to spend most of it's time resolving symbols into whatever they represent, so hashing is one way to find symbols quickly.  BUT, you can't have a Hash Table that has an entry for every possible combination of up to eight characters, so you have to find a way to "scrunch" the table down to something reasonable.  Besides, most combinations of characters will never be encountered, so the table would eat up large amounts of memory with useless symbol entries.  Maybe we've got to map 8 character names into a Hash Table that only has 1000 entries.  We could do something like adding up the value of all the letters in the symbol name, and make sure that we don't generate an illegal index using the MOD function (limiting the value to something between 0 and 999, so we get a valid index).  MOST eight character symbols won't map to the same index, but sometimes we're going to run into something like "MYSYM" and "SYYMM" which will both produce the same index (using our simple method).  This is called a "collsion" (because the two symbols "colide" by pointing to the same table entry).  There are lots of tricks and complex ways to hash a string to reduce collisions, but that, and a number of other issues, are too complex to go into here.  Making the table larger and producing a larger range of indexes (say 2000 instead of 1000 entries) is another way to reduce collisions, and we say that a big hash table with only a few entries is "sparsely populated."  Sparsely populated hash tables have fewer collisions.  So far, except for the problem with collisions, I hope I've explaned this well enough for it to seem as simple as it is.  Collisions are tougher though, because no matter what you do, when you reduce the hash so that there are fewer indexes than symbol possibilities, you will eventually have collisions.  As a result, there are also lots of ways people have come up with to deal with collisions.  One good approach is to take the two symbols that collide, put a marker in the hash table to indicate that there was a colision, and "rehash" the two symbols.  Rehashing must means to hash again, but using a different hashing method that produces different numbers.  Later when you are looking up the symbols in the table, you see that you have an index that points to a rehash, so you rehasn, and see where the symbols actually got stored.  If that too leads to another rehash, you might rehash again, or you might store symbols that are piling up (requiring too many rehashes) in another format, like a binary linked list or even a small sorted list that you access with a binary search.

    I'm not sure the discussion of more complex hashing is at all clear, but hopefully the simple case is understandable.  Complex hashing can be a bit tough, but it's not really that hard to understand.  Binary trees were often used as an alternative, becuase in many applications they can be just as quick, if not quicker.  Once a hashing process starts thrashing with too many collisions it can be a very slow, and this *can* happen with a relatively small set of symbols.  With a binary tree you things don't start slowing down greatly until the symbol table gets really big.  Sometimes it was hard to decide whether it was better to hash or use a tree, but now the only time it make sense to write code for either is in trivial cases like the one above (and I'm not even sure this is any kind of improvement over using a Dictionary).

    The one advantage with my code is that IF YOU ARE TRANSLATING characters to alternate characters, it's almost trivial to write the "translation string" that produces the hash table, and that's only important if it's important.  ;-)

    LOL, I sure hope I at least answered some part of your question, because that was HARD to write.  :-)

    Feel free to ask questions.  I'm sure I haven't explained this very well.

    Thursday, July 31, 2008 7:45 AM
  • Hi Red
    Excellent descriptions :)
    Just a quick reminder - VBers are aware of binary trees - they crop up pretty often in treeview controls and such like - its just a pity such may be lost in terminology - e.g. I wonder ho many vbers know just what a node actually is? A node is not just some pretty icon in a view control - it means 'knot' from the Latin and is an intersection of paths (crossroads if you like) in a network - again terminology lol - don't mean network as in just two or more PCs but in a wider sense of 'branches' and decision trees and such stuff.

    e.g.             A
                    /    \
                    B   C
                         /\
                        D E

    is a tree or network A and C would be 'decisions' i.e. IF or CASE statements in a program.
    Allan (who will stop there now cos too tired to continue)

    Thursday, July 31, 2008 9:21 AM
  • Red, re. Translation arrays: I think the OP answered that question :)

    Actually, that was my first thought, but as the OP stated, a single character may translate to multiple letters or words. That's why I used a char/string dictionary.

    Adding all chars to the dictionary means a lot of lines of code, but I think fairly readable. Copy/paste works wonders. However, an alternative is to create a text file of the format (for example):

    1=a
    2=B
    etc...

    and read each line in the file, loading it into the dictionary. In this way you could even store multiple files for different conversions. Additionally, you can add those files as resources to the compiled program and read them from there without having to have text files floating around the application folder.

    I was a very big VB6 proponent (as well as being a 'non-oop' person) - until VB2005 came along. VB2005 and later is so superior to anything previous, it's just not funny. 2002/2003 left a lot to be desired in the IDE. Now, I hardly ever use arrays for any work: lists and dictionaries are much easier and more reliable to work with, with no performance penalty. Using For/each loops, also, can eliminate a lot of headaches and aid readability.

    So, Bad Form? No, not really. But you tend to miss out on the ease at which these 'new' objects can be implemented. It speeds up your work no end, and lends itself to you solving real world problems, rather than wrestling with the fact that your index counter wasn't quite right, or you have to do some silly array redimension, and so on.
    Stephen J Whiteley
    Thursday, July 31, 2008 1:23 PM
    Moderator
  • Hmmm I don't quite agree with the 'no performance penalty'. Yes lists and collectiions are very nice and easy - I suspect dictionaries are too - but arrays are likely to be quicker and genuine linked lists (which VB.Net DOES NOT appear to have) will be much, much quicker and much more efficient.

    For example, try adding (sorry, inserting) or deleting an item in the middle of a list - and all the overheads that bring as you or VB as huge portions  of the list are moved about. With 'roll-your-own' linked lists, the data remains as is, and insertions, like additions, are just appended to the list - and just pointers (usually only a couple or a few pointers) need adjusting which can be blistering quick - especially in link list files.

    Allan

    Thursday, July 31, 2008 1:52 PM
  • Thanks you two.  Great explanations. (Yes, I read it all ;-))

    I'm still curious on what the entire code for Red's TranslationArray was. That seems to be what the ConvertDictionary code does but it uses arrays instead of a dictionary.
    Thursday, July 31, 2008 3:42 PM
  • The TranslationArray goes on the assumption that characters, specifically the ASCII code for characters are in a specific order. When you know the starting ASCII code, you have a base line to start looking at indexes in your array of characters.

    This is what used to be done with VB6, or VB 'classic'. It worked, but was prone to errors unless the programmer accounted for them (for example, you need to check that the character has a 'valid' ASCII code). It's also a little bit detracted from what you were trying to achieve.

    The above is disregarding the fact that you want a single character to be replaced by multiple characters, or a string...making this specific implementation unsuitable.

    The 'dictionary' is an array underneath it all, but has the versatility of accessing your 'array' from almost every angle (key, value or index), rather than just by index. Generally, in the real world, no-one cares about indexes. Your application is a prime example. A lot of programmers tend to overemphasize indexes, because those are the tools with which they have had to deal with for decades - it's difficult to wean them off it: it took me about a year to stop using arrays unnecessarily. All those algorithms for doing various functions have been encapsulated into base functionality (for example, who needs to program a sort algorithm? It's already built in!)


    Stephen J Whiteley
    Thursday, July 31, 2008 4:14 PM
    Moderator
  • Thanks for clearning that up for me, Stephen. My goal was achieved, I just wanted to learn more about "hashes"
    Thursday, July 31, 2008 4:16 PM
  • bigamee said:

    Hmmm I don't quite agree with the 'no performance penalty'. Yes lists and collectiions are very nice and easy - I suspect dictionaries are too - but arrays are likely to be quicker and genuine linked lists (which VB.Net DOES NOT appear to have) will be much, much quicker and much more efficient.

    For example, try adding (sorry, inserting) or deleting an item in the middle of a list - and all the overheads that bring as you or VB as huge portions  of the list are moved about. With 'roll-your-own' linked lists, the data remains as is, and insertions, like additions, are just appended to the list - and just pointers (usually only a couple or a few pointers) need adjusting which can be blistering quick - especially in link list files.

    Allan



    Allan, what makes you think .Net doesn't have a linked list? (look up LinkedList(of T)) Likewise, what makes you think that .Net 'moves' portions of a list around when you insert something? Wouldn't you think that inserting some random object into a list just inserts that pointer into the list? I know you'll find an less than significant performance difference between using the built in Collection objects and coding it by hand.

    I'd say give them a try: there's no proof (or disproof) than doing it yourself. I will say, though, that navigating all the available objects available to you is a task in and of itself. But most objects and functionality that has been coded previously is actually included in the framework. And if it isn't, it's quite easy to implement through inheritence or interfaces.

    Stephen J Whiteley
    Thursday, July 31, 2008 4:19 PM
    Moderator
  • SJWhiteley said:

    I was a very big VB6 proponent (as well as being a 'non-oop' person) - until VB2005 came along. VB2005 and later is so superior to anything previous, it's just not funny. 2002/2003 left a lot to be desired in the IDE. Now, I hardly ever use arrays for any work: lists and dictionaries are much easier and more reliable to work with, with no performance penalty. Using For/each loops, also, can eliminate a lot of headaches and aid readability.

    So, Bad Form? No, not really. But you tend to miss out on the ease at which these 'new' objects can be implemented. It speeds up your work no end, and lends itself to you solving real world problems, rather than wrestling with the fact that your index counter wasn't quite right, or you have to do some silly array redimension, and so on.


    Stephen J Whiteley



    Thanks Stephen.  Since I now only write code for my own entertainment and enlightenment I probably should't be so worried about "good form."  I don't know that I could say that I was actually a VB6 proponent like you, but starting with VB3, and when I feel like scratching out a little code, VB is always my first choice.  As for being an OOP person, I'm all for it when it's helpful, hate it when it gets in the way or gets too confusing, and struggle with what it now means to write good code.  It bothers me a little that I have so little visability into the internals, because (for example) if I write code that indexes into an array and finds stuff in a way that LOOKS direct and clean, I might actually be creating who knows how many array, string, or other objects, and what looks like clean code might actually be horribly gnarly just under the surface.  With OOP I'm not suppse to care or worry about such things, but the mindset that things like memory and processing power are unlimited doesn't come easily.

    As for VB itself, I missed everything between VB6 and VB2008 (Express), and I'm still too new to 2008 to be certain, but I fully agree with your assessment.  I've developed complex development environments that make the complexity of the underlying processes easy to access and use (and some if not all ISF's <aka Integration Support Facilities> are much more complex than say Vista).  There is always a tradeoff between keeping it simple for the user (programmers are users in this context) and giving them the power and flexability they need.  LOL, I'm not bold enough to say that we did great UI design, so I'll just say that for nearly two decades after we built the first ISF's, we were getting sole source contracts to build new ISF's, because our customers felt that we built the best tools available.  The ISF business grew from two projects into one of the biggest lines of business in the aerospace industry, so we *must* have been getting it right.  My point here is just that while my skills may be out of date, I have good reason to feel that I know a good development environment when I see one, and the entire Visual Studio is among the BEST development environments I've ever seen.  I can't really say that it's better or worse than the ISF environments, because there are too many differences, but I actually find it hard to come up with any complaints at all regarding the Visual Studio development environment.  The documentation needs to be fleshed out a little more, and the environment will probably be obsolete before the documentation is fully fleshed out, but with guys like Reed and you around to help us out, I frankly can't even imagine a better, more capable, or easier to use, deveopment environment.  We need it too, because our systems have gotten far too complex to manage without first rate tools.

    I've never been hard over on Microsoft, and have always been quick to boot to Linux, but I think the new NET Framework and new (to me) development tools are going to change all that.  There is a lot to learn, but I'm quite sure that it's going to be well worth the effort.

    Thursday, July 31, 2008 9:37 PM
  • Thanks Stephen
     Not actually met LinkedList(of T)) yet (but the Help in my vb2008 is incomplete) but I wll definitely have a look.  If (hopefully) we are talking the same thing then great :))) and I will most definitely use them :)
    But at least, hopefuly, me and Red have given some insight into the old ways and the thinking behind them. Many of the old ways HAD to be excellent - because on the 8-bit micros speed was slow - 4 MHz was about the highest processor clock speeds available. You were lliterally lucky if a machine ever hit a couple of MIPs (Millions of integer Instructions Per Second in machine code - i.e. just incrementing a processor register, say). In fact, it was
    more usual to generally talk about kIPS - thousands of machine code integer instructions per second.

    On MIPS, when manufacturers started quoting MIPS - as a selling point, the differences in h/w was often so much that we often joked that MIPS stood for "Meaningless Indicator of Processor Speed."
    When the 32-bit Archimedes RISC based machine and 32-bit 386s appeared, manufaturers of 'real' computers (IBM, ICL, Cray, etc.) began talking in terms of FLOPS on mainframes - FLOPS being the floating-point arithmetic equivalent of MIPS.

    Whoaa ok wandering a bit again lol

    Ok in the days of 4 Mhz Z80A processors, as opposed to 40 Mhz 386DXs and later, 64 KB was the most RAM you could expect on a machine - and you considered yourself damn lucky if you had 16KB of that to play with. So, out of sheer necessity,  techniques had to be developed that were necessarily fast, memory efficient, and hopefully readable and easily understood - even if some of the techniques involved quite a bit of coding. C was a 'natural' choice of systems programming language because it was a lean, mean computing machine (meaning its instruction set was small (about 30 keywords) and efficient to type and code) and that it had pointers which naturally lent themselves to using arrays and linked-lists quickly and efficiently. About 10 years ago I heard of some x86 competitions where you had to write games in x86 assembly language that had the following requirements: all the code, graphics, game logic, music etc. MUST FIT IN 32 Mb of RAM (no code overlays or any other cheats). This was an endeavour to keep the old programming skills and techniques alive. I had a copy of Gianna Sisters for the PC which won one of the competitions - a full (all 40 levels) classic arcade game - including all its music - that was only 32 Kb long.

    Another example of using the old skills is the Menuet OS for PCs - see http://www.menuetos.net/
    This remarkable little OS is written in, and for, x86 assembly - it's a 'Windows like' OS and it has a 'Windows like' GUI and desktop, it even has apps like a WebBrowser with it - and IT ALL FITS AND RUNS FROM JUST ONE 3.5" high density FLOPPY DISK!!! MS plz take note. You can even get games like DOOM for it. Now try telling me that .Net and OOP is efficient again lol
    Allan
    Thursday, July 31, 2008 11:03 PM
  • NolanLi said:

    Thanks for clearning that up for me, Stephen. My goal was achieved, I just wanted to learn more about "hashes"


    Hi,

    The simplest form of hashing or coding letters would be to replace letters with those further up or further down the dictionary in a circular manner like this.>>

    ABCDEFGHIJKLMNOPQRSTUVWXYZ   could become.>>
    ^^^^^^^^^^^^^^^^^^^^^
    HIJKLMNOPQRSTUVWXYZABCDEFG

    So an "A" becomes an "H" a "C" would become a "J" and so on, get it?




    Regards,

    John


    I have previously been, until recently, an MSP ( Microsoft Student Partner ).
    Friday, August 1, 2008 12:01 AM
  • John Oliver VSIP former MSP said:

    NolanLi said:

    Thanks for clearning that up for me, Stephen. My goal was achieved, I just wanted to learn more about "hashes"


    Hi,

    The simplest form of hashing or coding letters would be to replace letters with those further up or further down the dictionary in a circular manner like this.>>

    ABCDEFGHIJKLMNOPQRSTUVWXYZ   could become.>>
    ^^^^^^^^^^^^^^^^^^^^^
    HIJKLMNOPQRSTUVWXYZABCDEFG

    So an "A" becomes an "H" a "C" would become a "J" and so on, get it?




    Regards,

    John


    I have previously been, until recently, an MSP ( Microsoft Student Partner ).



    OR, you could just a shift left circular on each byte.  ;-)
    Friday, August 1, 2008 12:28 AM
  • Good work friends
    Sunday, November 15, 2009 8:35 PM
  • Hi,
    try this if possible

    Strings.Join(Array.Convert(TextBox1.Text.Split, Function (txtNum$) Chr(Integer.Parse(txtNum) + 96)), " ")


    Best regards, matt

    Monday, November 16, 2009 3:32 PM