Re: Move from VB 6 to VB.Net in 5 easy steps


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 6 123 ... LastLast
Results 1 to 15 of 85

Thread: Re: Move from VB 6 to VB.Net in 5 easy steps

  1. #1
    Jon Ogden Guest

    Re: Move from VB 6 to VB.Net in 5 easy steps


    "Jay Glynn" <jay_glynn@agla.com> wrote in message
    news:3a6ba6a0@news.devx.com...
    > Jon,
    >
    >
    > > Many of the changes seem to be designed simply to break compatibility.

    > They
    > > do not make VB.NET any more OO, they simply make it look 'cool.'
    > >

    >
    > They make it more compatible with the other languages that will be

    supported
    > on .NET.


    I wonder how compatible it will be with VB.Python...but even granting your
    premise, you are not disagreeing with me; just rephrasing in different
    terms.

    > > I have never have quarreled with the elegance of Fred.NET. And it

    > certainly
    > > can be considered a variant of the BASIC family. But by your own

    > testimony,
    > > it's not VB.

    >
    > It's not VB7. It's not a load and recompile migration from VB6, but I

    think
    > that you can still call it VB.


    Then it should be called PDS 14. It has little if anything more in common
    with VB6 than VB1 had with QBX. Why keep the name the same this time?

    > > Why is it, I wonder, that anyone who likes VB.NET starts off by assuming
    > > that anyone who doesn't is an ignoramus? I'm reading your opinions

    pretty
    > > carefully and with an open mind. You seem to want to discount mine in
    > > advance by assigning me a history that makes you feel superior.

    >
    > Never meant to imply anything like that. Simply if all you know is VB,

    then
    > the changes make less sense then if you have done a fair amnount of C /C++
    > programming or perhaps Java programming.


    "Make sense?" If you mean recognisable, then I agree with you. If you mean
    more likely to be deemed "A Good Thing," I have doubts. If you mean that
    someone who has programmed primarily in other languages will feel more
    comfortable with Fred, then, again, I agree.

    >Then the changes would ring a
    > familiar bell. I am not trying to infer that this has a direct

    relationship
    > to your intellect, or to your development skills. Apologies if it came
    > across that way.


    Accepted with thanks.
    > > >The boolean -1
    > > > to not 0, the 0 based arrays etc are being handled the way that most
    > > > languages currently handle them.

    > >
    > > Most languages are different from each other. MSFT recognized this re:

    C++
    > > and VFP. Only VB was changed to be a semi-clone of C#.

    >
    > VB was the only on that did them differently.
    >


    The three languages (VB; C++; VFP) all do many things differently than each
    other and C++ and VFP have not been coerced into doing them the same way as
    C#.

    > >My concern these
    > > past weeks has been to determine whether or not dealing with VB.NET is a
    > > waste of time. Nothing you have said in your post suggests that VB.NET
    > > offers any greater ROI than C# and, since the success of dotnet is still
    > > problematical and its adoption as a desktop standard even more so,

    > switching
    > > to Java, or Kylix must be looked at as a viable alternative. Especially
    > > since the suits will consider dotnet to be experimental and unproven.

    (And
    > > rightfully so, it is.)
    > >

    >
    > As far as overall adoption, yes we are all waiting to see what happens.


    More importantly, so are our bosses <grin>.

    > However as far as ROI goes, I think that VB.NET will allow a current Vb
    > developer to be much more productive then if they were to have to learn

    C#.
    > There is still a great deal of syntax that is still VB, and there is
    > VisualBasic.dll that will make the learning process much easier.


    You may be right. Or that may lull folks into a false sense of security.

    > > >The there is the argument about it not
    > > > being as easy to learn. In my mind this is a good thing.

    > >
    > > Okay, in your mind it is. In other peoples minds it isn't. If some

    people
    > > think VB's more accessible than other languages, then what skin is it

    off
    > of
    > > your nose? It probably creates extra income for you when you are asked

    to
    > > bail them out. At any rate it's an opinion and not a matter of fact.
    > >

    >
    > No, unfortunately it isn't extra income, it's just extra time that I don't
    > have. I work in Corporate America., my paycheck is the same each week
    > regardless.


    Yeah, me, too. Difference is I like working with the newbies. They're like
    puppies - not fully toilet trained, but cute and eager. And my bosses let
    me track mentoring time as a separate project that is on-going.

    > > Your point has nothing to do with the language, but seems to suggest

    > you'll
    > > feel better if you can say that you know a lnaguage thats not easy to

    > learn.
    > > So what's stopping you?
    > >

    >
    > It has everything to do with the language, or at least in the MSFT

    marketing
    > of the language. Everyone knows that VB is easy to learn and to use, or
    > that's what we all have been told. The guy in marketing thinks that means

    he
    > can write a new front end to his marketing database. He was told that if

    you
    > put the database name in this spot and the table name in this spot, the

    data
    > magically appeared in the grid. He had no clue about ADO, RDO, ODBC,
    > recordset, what DBMS he was using, never mind that the grid he wanted

    would
    > have required a 4 table join (his response "What's a join?"). This is not
    > easy to use,


    I agree. Hey in your corp, who decides these guys get VB on their desktop?
    That sounds like it's your real problem, not the jamoke who is using the
    tools he's been told to use. It's the folks who are okaying the install that
    you need to educate. I wouldn't be surprised if they are C++ folks, or
    sysadmins who haven't looked as a BASIC-derived language since an intro to
    VB3 in college.

    > > > Bottom line to all of this is that we, the professional developers

    that
    > > give
    > > > a crap about our future, that actually read book on occasion, that try

    > to
    > > > keep up with technology, now have multiple choices. You can stick with
    > > > current version of VB. I see this to be a viable option for at 2 to 3

    > > years.
    > > > Move to .NET. Now you really have a choice of languages. Move to

    Delphi
    > > and
    > > > hope that Borland stays afloat (see Hindenburg). Pick up Java and hope

    > > that
    > > > Sun does the right thing. Of course you won't be doing to many client

    > > based
    > > > apps, otherwise your users will hang you for the performance hit <g>.

    > And
    > > > then of course there is C++ if your feeling really geaky and you have

    a
    > > long
    > > > development cycle. I can't imagine a better time to be in this

    business.
    > >
    > > Interesting. We basically agree - although I think your time estimates

    for
    > > dotnet are way optimistic and I'm as much concerned about the
    > > performance-hit that client-based apps will take with dotnet as with

    Java.
    > > However, and at the risk of repeating myself - why bother with VB.NET?

    If
    > > there were a viable migration path from what there is to what MSFT wants
    > > there to be, that would make a difference. If there weren't all the
    > > gratuitous incompatibilities, that would make a difference. If VB.NET

    was
    > > seen as the big pile of goo that maintained compatibility and VB# was

    seen
    > > as the really cool way to go for people who knew hard to learn

    languages,
    > > that would make a difference too. Any of the preceding would make me

    feel
    > > better about VB.NET's long-term prospects.

    >
    > The fact that MSFT has stated that VB6 will be around for a couple of more
    > years answers your question. I don't look at it as a migration path. I

    still
    > have VB3 apps in production. I answered the why VB.NET before, because it
    > will be easier to learn for a seasoned VB developer.


    Of course, my mileage may vary. Presumably your prognostications carry a
    money back guarantee only for as much as I paid for 'em.

    Good Luck



  2. #2
    Jon Ogden Guest

    Re: Move from VB 6 to VB.Net in 5 easy steps


    "Jay Glynn" <jay_glynn@agla.com> wrote in message
    news:3a6ba12f$1@news.devx.com...
    > Bottom line, you can't tell me that someone hasn't snickered at you when

    you
    > say you are a Vb developer, saying something to effect of when are you

    going
    > to use real tools etc etc etc. This is because of MSFT marketing saying

    how
    > easy it is. There was a meeting of managers not to long ago. They wer
    > looking at the salary structure, making sure that we were competitive in

    the
    > current market. A long time COBOL developer now manager made the statement
    > "VB programmers should not be making as much as COBOL programmers.

    Everyone
    > knows VB is easier to use." This is the kind of attitude that I am getting
    > tired of. If that makes me arrogant, so be it.
    >


    Nope, the technical term is defensive. I understand feeling that way from
    time to time and I've heard the same stuff. However, it's all a pssing
    contest and if you think it'll stop because of VB.NET, I'll offer the
    money-back guarantee that it won't. If you were a COBOL programmer, you'd
    be angry because everyone called you a dinosaur.

    Good luck,
    Jon



  3. #3
    Jay Glynn Guest

    Re: Move from VB 6 to VB.Net in 5 easy steps

    Jon,

    > Nope, the technical term is defensive. I understand feeling that way from
    > time to time and I've heard the same stuff. However, it's all a pssing
    > contest and if you think it'll stop because of VB.NET, I'll offer the
    > money-back guarantee that it won't. If you were a COBOL programmer, you'd
    > be angry because everyone called you a dinosaur.
    >


    You may be right, but I hope that the attitude changes somewhat. It just
    gets annoying.

    --
    Jay Glynn
    Introducing .NET
    ISBN: 1861004893
    Wrox Press Ltd.



  4. #4
    mrfelis Guest

    Re: Move from VB 6 to VB.Net in 5 easy steps

    Bob Butler <butlerbob@earthlink.net> wrote in message
    news:3a69f978@news.devx.com...
    > Actually, for me the alternative is probably more like:

    Honestly, I had originally coded the alternate as:
    if x<5 and y<5 then
    i=3
    elseif y<5 then
    i= 2
    elseif x<5 then
    i=1
    end if

    But i figured some one would complain. This isn't far off from what you have
    here:

    > If x<5 then
    > if y<5 then
    > i=3
    > else
    > i=1
    > end if
    > elseif y<5 then
    > i=2
    > else
    > i=0
    > end if


    And how would you write the code for a condition like:

    x<5 -> 1
    y<5 -> 2
    x<5 and y<5 -> 3
    z<5 -> 4
    z<5 and x<5 -> 5
    z<5 and y<5 -> 6
    z<5 and y<5 and x<5 -> 7

    The expression:
    i = (cint(x<5) and 1) + (cint(y<5) and 2) + (cint(z<5) and 4)

    is very consice. If you are fimiliar w/ boolean arithmetic, it is also very
    obvious what is going on. So why did MS take boolean arithmetic away from
    us?

    x<5 will be either true or false.
    cint() converts this to 0 or -1 (no ibts set vs all bits set)
    And 1 returns 0 or 1.

    > Personally, I prefer the If/Then construct simply because I find

    maintenance
    > easier. When code is condensed down using IIF or conversion of boolean to


    I'd say the opposite to be true since code is being repeated. If the
    condition of y<5 needs to be changed to y<10, will the programmer remember
    to change both y<5 expressions? If the boss is breathing down the
    programmer's neck, most likely no. (You have to make 4 changes for the three
    independent changes - using an extension of your sample above.)

    Now you and I know that this is the reason for constans. However, would you
    have defined two constants (1 for x and 1 for y) that were both 5? This
    would be even more prone to errors since we would have add a new constant,
    and use this new constant in the correct place.

    The more changes that have to be made, the more chance Murphy has to do his
    magic.
    --
    ~~~
    !ti timda I ,KO
    ..em deppals nocaeB sivaM
    !draH
    ~~
    C'Ya,
    mrfelis@yahoo!com
    Bob Butler <butlerbob@earthlink.net> wrote in message
    news:3a69f978@news.devx.com...
    >
    > "mrfelis" <mrfelis@yahoo.NOSPAM.com> wrote in message
    > news:3a69d0e1$1@news.devx.com...
    > > > > CInt(Bool)
    > > >
    > > > Ok ... btw, I've never ever done that sort of thing. Maybe I just

    don't
    > > > write clever algorithms. What's the point of converting bools to

    ints?
    > > Say you need a number 1 if x is <5, a 2 if y is < 5, or a 3 if x<5 and

    > y<5.
    > >
    > > The following line of code will do this (in VB 6):
    > > i = (cint(x<5) And 1) + (cint(y<5) And 2)
    > >
    > > The alternative is:
    > > i = 0
    > > if x<5 then
    > > i = i +1
    > > end if
    > > if y<5 then
    > > i = i + 2
    > > end if

    >
    > Actually, for me the alternative is probably more like:
    > If x<5 then
    > if y<5 then
    > i=3
    > else
    > i=1
    > end if
    > elseif y<5 then
    > i=2
    > else
    > i=0
    > end if
    >
    > and you could also use something like:
    > i=iif( x<5, iif(y<5,3,1),iif(y<5,2,0))
    >
    > Personally, I prefer the If/Then construct simply because I find

    maintenance
    > easier. When code is condensed down using IIF or conversion of boolean to
    > integer it quickly becomes easy to read it wrong. Unless there's a

    pressing
    > need to optimize execution the longer code is best IMO.
    >
    > That still does not mean that changing Boolean from -1 to +1 in VB.Net was

    a
    > good thing.
    >
    >
    >




  5. #5
    Bob Butler Guest

    Re: Move from VB 6 to VB.Net in 5 easy steps


    "mrfelis" <mrfelis@yahoo.NOSPAM.com> wrote in message
    news:3a6c5571@news.devx.com...
    > Bob Butler <butlerbob@earthlink.net> wrote in message
    > news:3a69f978@news.devx.com...
    > > Actually, for me the alternative is probably more like:

    > Honestly, I had originally coded the alternate as:

    <cut>
    > But i figured some one would complain.


    Somebody will always complain no matter how you write it. <g>

    > And how would you write the code for a condition like:
    >
    > x<5 -> 1
    > y<5 -> 2
    > x<5 and y<5 -> 3
    > z<5 -> 4
    > z<5 and x<5 -> 5
    > z<5 and y<5 -> 6
    > z<5 and y<5 and x<5 -> 7


    I might use a nested If/Then construct... I might use the booleans and bit
    masks... I might do something like:
    i=0
    If x<5 then i=1
    If y<5 then i=i+2
    if z<5 then i=i+4

    A lot depends on the overall context of the calculation in relation to the
    rest of the code, the expected lifetime of the app and ho is likely to be
    maintaining it.

    > The expression:
    > i = (cint(x<5) and 1) + (cint(y<5) and 2) + (cint(z<5) and 4)
    >
    > is very consice. If you are fimiliar w/ boolean arithmetic, it is also

    very
    > obvious what is going on.


    I guess I've worked too long with people who don't understand the bit-level
    manipulations; it isn't the boolean to integer that confuses them when
    working on the code but rather the " (-1 And 4) " part that gets them lost.
    Being too concise in the code doesn't help when you need several lines of
    comments to explain it.

    > So why did MS take boolean arithmetic away from us?


    You can still do: i=(cint(x<5)) + (2*cint(y<5)) + (4 * cint(z<5))

    > x<5 will be either true or false.
    > cint() converts this to 0 or -1 (no ibts set vs all bits set)
    > And 1 returns 0 or 1.
    >
    > > Personally, I prefer the If/Then construct simply because I find

    > maintenance
    > > easier. When code is condensed down using IIF or conversion of boolean

    to
    >
    > I'd say the opposite to be true since code is being repeated. If the
    > condition of y<5 needs to be changed to y<10, will the programmer remember
    > to change both y<5 expressions? If the boss is breathing down the
    > programmer's neck, most likely no. (You have to make 4 changes for the

    three
    > independent changes - using an extension of your sample above.)


    If it's all together in a few lines of code then it is not so likely to be
    missed.

    > Now you and I know that this is the reason for constans. However, would

    you
    > have defined two constants (1 for x and 1 for y) that were both 5? This
    > would be even more prone to errors since we would have add a new constant,
    > and use this new constant in the correct place.


    If the two constants represented different things then I probably would. As
    an example, vbNormal is a Windowstate constant with a value of zero and
    vbDefault is a MousePointer constant with a value of zero. Since they
    represent different things they are unique constants even though they have
    the same value. In the case you mentioned having a constant to represent
    "5" means I may as well just use the literal value. Having a constant for
    the "X-limit" and another for the "Y-limit" makes sense to me even if they
    both happen to be 5 at the current time.

    > The more changes that have to be made, the more chance Murphy has to do

    his
    > magic.


    And the clearer and more explicit the code is the less likely he can worm
    his way in. If I am coding something for myself only then I do use
    "tricks" like the bit masks and boolean operations to reduce the amount of
    code. If I'm coding something that may need to be maintained by somebody
    else then I try to avoid them. Since I don't know the skill level of the
    person who will need to work on it I just find it works best to be a little
    more verbose, either in code or comments or both. YMMV





  6. #6
    Dan Barclay Guest

    Re: Move from VB 6 to VB.Net in 5 easy steps

    On Sat, 20 Jan 2001 21:15:12 -0800, "Michael \(michka\) Kaplan"
    <former_mvp@spamfree.trigeminal.nospam.com> wrote:

    >Actually, THAT anger is for entirely different reasons, they are not going
    >through these stages.


    True fact.

    Dan
    Language Stability is a *feature* I wish VB had!
    (#6)

  7. #7
    Zane Thomas Guest

    Re: Move from VB 6 to VB.Net in 5 easy steps

    "mrfelis" <mrfelis@yahoo.NOSPAM.com> wrote:

    >The following line of code will do this (in VB 6):
    >i = (cint(x<5) And 1) + (cint(y<5) And 2)


    I understand your example, and the more complex one where x is x(). But
    still I don't understand how you would frequently arrive at a situation
    where computed numeric values need to be converted to booleans. It seems
    somehow that you're computing integers when you want booleans.

    I suppose maybe there are situations where there is no alternative design.
    I don't recall every seeing one myself, in 25 years of programming. I
    guess that's either because I work on different sorts of problems, or
    maybe because I design differently.

    What I'd like to _suggest_ is that perhaps you were influenced in your
    design by knowing that you could use what appears to me as a risky
    solution and that if you had tried to avoid that situation you would have
    had a design which different. That's what I've been trying to say in this
    thread - that designing to take advantage of oddities of a language is not
    necessarily a good idea.


    ---
    Ice Z - Straight Outta Redmond

  8. #8
    Zane Thomas Guest

    Re: Move from VB 6 to VB.Net in 5 easy steps

    "Jon Ogden" <jon@ogdenco.net> wrote:

    >> >What is your guess as to which dotnet language you will use the most?

    >>
    >> C#

    >
    >I am beginning to believe that answer holds for me, too.


    You should know that I've been writing components in c/c++ for the past
    many years (since vb1) and so c# is a natural for me.

    >but maybe we aren't really speaking the same language. Perhaps you'd like
    >to give your (re)definition of the word "incompatible?"


    I don't see any point in getting into such a discussion.


    ---
    Ice Z - Straight Outta Redmond

  9. #9
    mrfelis Guest

    Re: Move from VB 6 to VB.Net in 5 easy steps

    Zane Thomas <zane@mabry.com> wrote in message
    news:3a776dd3.582968671@news.devx.com...
    > >i = (cint(x<5) And 1) + (cint(y<5) And 2)

    > somehow that you're computing integers when you want booleans.


    Nope, I don't want booleans. The expression return return booleans. I'm
    converting them. The function feeds a state machine (select case) based on
    the conditions provided.

    > What I'd like to _suggest_ is that perhaps you were influenced in your
    > design by knowing that you could use what appears to me as a risky
    > solution and that if you had tried to avoid that situation you would have

    Had this been a risky soultion, MS would not have documented (and very well
    at that) that True = -1. MS well knows the principals of undocumented code
    as evidenced by the extent of undocument DOS API functions they implemented
    in the 80's and didn't tell anyone about.

    Using undocumented features was considered risky since MS didn't want to be
    bound by those features and reserved the right to change them at will.
    Changing a documented rule is the equivalent of breaking a contract.

    How happy would you be if mathmaticians decided to decide that 1+1=3? MS
    made booleans that way: Not 0 = -1. Not False should = True. I assume this
    is the reason Fred doesn't support bitwise operators anymore.

    > had a design which different. That's what I've been trying to say in this
    > thread - that designing to take advantage of oddities of a language is not
    > necessarily a good idea.

    Boolean algebra isn't an oddity. It is the foundation of digital
    electronics, and by extension, computers and programming. So what oddity are
    you talking about?


    --
    ~~~
    !ti timda I ,KO
    ..em deppals nocaeB sivaM
    !draH
    ~~
    C'Ya,
    mrfelis@yahoo!com



  10. #10
    Joe \Nuke Me Xemu\ Foster Guest

    Re: Move from VB 6 to VB.Net in 5 easy steps

    "Michael (michka) Kaplan" <former_mvp@spamfree.trigeminal.nospam.com> wrote in message <news:3a6c45ae$1@news.devx.com>...

    > It seems likely that it will NOT change, except to get worse, all things
    > considered.
    >
    > But people ahve been rationalizing this one with each version, so its
    > unsurprising that people such as yourself would rationalize now....


    It *will* be different this time, if only the name were to actually
    change to Fred. IMH(?)E, the cow-orkers who snickered at Visual
    BASIC took Access apps seriously, simply because I'd always say
    "Access Script Language" instead of "Visual Basic for Applications".
    Yeesh!

    --
    Joe Foster <mailto:jfoster@ricochet.net> Space Cooties! <http://www.xenu.net/>
    WARNING: I cannot be held responsible for the above They're coming to
    because my cats have apparently learned to type. take me away, ha ha!



  11. #11
    Joe \Nuke Me Xemu\ Foster Guest

    Re: Move from VB 6 to VB.Net in 5 easy steps

    "Mark Burns" <mark@iolofpa.com> wrote in message <news:3a6c2de8@news.devx.com>...

    > "Mike Mitchell" <visual.basic@freeuk.com> wrote in message
    > news:3a6a0587$1@news.devx.com...


    > > call each other names, we shake our fists, and soon there's blood on the
    > > carpet and the opinions are more entrenched than ever.
    > >
    > > We're humans. It's what we do.

    >
    > Correction: It's what we do <by default?> when we're too
    > stupid/arrogant/prideful to understand there's a better way, then find that
    > better way, and use it.


    Naah, too much trouble to track the guy down, since his project at
    a different company is on a death march and his team leader's locked
    everybody in a dungeon to keep them from being distracted by useless
    stuff like sleeping, bathing, eating, spouses, children, therapy
    appointments, or divorce court appearances, let alone pesky former
    cow-orkers with a question about old code...

    --
    Joe Foster <mailto:jfoster@ricochet.net> Got Thetans? <http://www.xenu.net/>
    WARNING: I cannot be held responsible for the above They're coming to
    because my cats have apparently learned to type. take me away, ha ha!



  12. #12
    mrfelis Guest

    Re: Move from VB 6 to VB.Net in 5 easy steps

    Bob Butler <butlerbob@earthlink.net> wrote in message
    news:3a6c5a19$1@news.devx.com...

    > > But i figured some one would complain.

    >
    > Somebody will always complain no matter how you write it. <g>

    Don't I know it!

    > > And how would you write the code for a condition like:

    > A lot depends on the overall context of the calculation in relation to the
    > rest of the code, the expected lifetime of the app and ho is likely to be
    > maintaining it.


    True enough. It depends on what you're doing. It should never depend on what
    a private corperation feels like changing though!

    In corperate America, I find it unlikely to know who is going to inherit my
    code. I've found code broken in my own projects (very simple things - no
    tricks involved) that other developers have made. I've also worked
    concurrently with a very green programmer who didn't understand the concept
    of the IF statement. I came to work one morning to find that a very large
    section of code had been changed. The programmer who did this had duplicated
    the bulk of one the program and placed an IF..else..endif around the new and
    old code. The new code was 99% identical to the old code; only 2 lines had
    been added - one immediately followed the other.

    So, I'm not really sure it is a valid notion to code to the lowest
    denominator in programming skills. How far can you take it? I fell whoever
    inherits code needs to get up to speed on how the code works.

    > I guess I've worked too long with people who don't understand the

    bit-level
    > manipulations; it isn't the boolean to integer that confuses them when
    > working on the code but rather the " (-1 And 4) " part that gets them

    lost.
    > Being too concise in the code doesn't help when you need several lines of
    > comments to explain it.

    Why not? Comments don't break code.

    >
    > > So why did MS take boolean arithmetic away from us?

    >
    > You can still do: i=(cint(x<5)) + (2*cint(y<5)) + (4 * cint(z<5))

    Ironically, this requires a ABS() around the entire thing to work in VB6.

    >
    > > x<5 will be either true or false.
    > > cint() converts this to 0 or -1 (no ibts set vs all bits set)
    > > And 1 returns 0 or 1.
    > >
    > > > Personally, I prefer the If/Then construct simply because I find

    > > maintenance
    > > > easier. When code is condensed down using IIF or conversion of

    boolean
    > to
    > >
    > > I'd say the opposite to be true since code is being repeated. If the
    > > condition of y<5 needs to be changed to y<10, will the programmer

    remember
    > > to change both y<5 expressions? If the boss is breathing down the
    > > programmer's neck, most likely no. (You have to make 4 changes for the

    > three
    > > independent changes - using an extension of your sample above.)

    >
    > If it's all together in a few lines of code then it is not so likely to be
    > missed.

    Unfortunately, unless your he only one to work on the code, you can never
    ensure that will remain the case.

    > > Now you and I know that this is the reason for constans. However, would

    > you
    > > have defined two constants (1 for x and 1 for y) that were both 5? This
    > > would be even more prone to errors since we would have add a new

    constant,
    > > and use this new constant in the correct place.

    >
    > If the two constants represented different things then I probably would.

    As
    > the "X-limit" and another for the "Y-limit" makes sense to me even if they
    > both happen to be 5 at the current time.


    I'll give you that one.

    >
    > > The more changes that have to be made, the more chance Murphy has to do

    > his
    > > magic.

    >
    > And the clearer and more explicit the code is the less likely he can worm
    > his way in. If I am coding something for myself only then I do use
    > "tricks" like the bit masks and boolean operations to reduce the amount of

    Often enough, tricks are reqyuired to make the impossible possible. Video
    games are the typical breeding ground of such "unorthodox" tactics.

    > code. If I'm coding something that may need to be maintained by somebody
    > else then I try to avoid them. Since I don't know the skill level of the
    > person who will need to work on it I just find it works best to be a

    little
    > more verbose, either in code or comments or both. YMMV
    >


    I'm a bit intolerant here. If a programmer can't understand the code by
    looking at it then he should step through it and figure out what is going
    on. If he can't do that, he ain't worth his salt.

    --
    ~~~
    !ti timda I ,KO
    ..em deppals nocaeB sivaM
    !draH
    ~~
    C'Ya,
    mrfelis@yahoo!com



  13. #13
    Sjoerd Verweij Guest

    Re: Move from VB 6 to VB.Net in 5 easy steps

    > But VB *is* easier to use. After all, I once managed to whip out a
    > live demo that exceeded capacity and responsiveness requirements
    > even on the old Dauphin DTR-1 I scrounged up on a lark (or maybe
    > just to be "arrogant"?) while the MFC gurus were still chasing GPFs
    > and wondering why populating list boxes was taking 90 seconds plus!


    Erm, that's because you know how to *program*. We're talking users trying to
    program (and defaming the language because of it), not programmers using VB
    as the extremely productive programming language it is.




  14. #14
    Jonathan Allen Guest

    Re: Move from VB 6 to VB.Net in 5 easy steps

    > The expression:
    > i = (cint(x<5) and 1) + (cint(y<5) and 2) + (cint(z<5) and 4)
    >
    > is very consice. If you are fimiliar w/ boolean arithmetic, it is also

    very
    > obvious what is going on. So why did MS take boolean arithmetic away from
    > us?
    >


    That isn't Boolean Arithmetic as defined in mathematics. If it was, the +
    would mean the same as Or and the resulting i could only equal 1 or 0.

    From what I can tell, what you are trying to do is still possible by using
    BitAnd.

    --
    Jonathan Allen





  15. #15
    Zane Thomas Guest

    Re: Move from VB 6 to VB.Net in 5 easy steps

    "mrfelis" <mrfelis@yahoo.NOSPAM.com> wrote:

    >Zane Thomas <zane@mabry.com> wrote in message
    >news:3a776dd3.582968671@news.devx.com...
    >> >i = (cint(x<5) And 1) + (cint(y<5) And 2)

    >> somehow that you're computing integers when you want booleans.

    >
    >Nope, I don't want booleans. The expression return return booleans.


    Actually in both cases, x and x(), the expression you started with was an
    integer which you then converted to boolean, then to bitwise boolean, and
    then to an arithmetic expression. It's that mixing of boolean and integer
    operations that I cannot recall having ever seen the need for.

    >I'm converting them. The function feeds a state machine (select case)
    >based on the conditions provided.


    Having done a fair amount of realtime programming I'm very familiar with
    state machines. You rejected, prima facie apparently, the use of
    intermediate variables to hold results such as x() < 5. I wouldn't do
    that, instead viewing the intermediate variables as a way to provide
    symbolic names which when used in a boolean expression which actually
    clarififies the logic of the situation. Of course I don't think most code
    needs much in the way of comments when written that way. My sense of the
    situation being that it makes a lot more sense to read code, which never
    lies, as opposed to comments which are not executable.

    >How happy would you be if mathmaticians decided to decide that 1+1=3?


    I might be very happy if some class of problems could be better solved
    with such a redefinition. But I probably wouldn't use it for balancing my
    checkbook.

    >> had a design which different. That's what I've been trying to say in this
    >> thread - that designing to take advantage of oddities of a language is not
    >> necessarily a good idea.

    >Boolean algebra isn't an oddity. It is the foundation of digital
    >electronics, and by extension, computers and programming. So what oddity are
    >you talking about?


    I never said boolean algebra is an oddity, so let's leave that strawman
    for the crows ok? What I did say is that mixing integer and boolean
    expressions seems unnecessary and odd. As I described above I prefer to
    make the distinction clear to the reader by making the transition from
    integer to booleans explicit in the code.


    ---
    Ice Z - Straight Outta Redmond

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center