No troll. What are the (legitimate) reasons people are still using VB6 ?

Might be impossible, in that case. That would explain a whole lot. They may be paying a portion of the VB6 license cost to third parties, so a portion of the purchase price goes to them. That would make it pretty much impossible to either open source or make it freeware. MS might not care, but those third parties would have a straw in the pool, as well.

Quote:

---

Originally Posted by dilettante

I suspect that a lot of things included with VB6 were licensed from 3rd parties, mostly controls. It might be a lot of trouble to get clearance to release them at this late date.

---

I certainly don't know, but I do sort of question that. Do we think that Microsoft was paying third-parties royalties for each copy of the VB6 IDE it sold? That's difficult to believe (but, I suppose not entirely impossible). If they're not paying any royalties, you'd think they could set whatever price they wanted, even $0.00. Even if there were some licensing issues, you'd think that Microsoft would have unlimited distribution rights for whatever they were. I could see that as being a possible impediment to opening the source, but not necessarily forgoing licensing fees.

Just my two-cents. And again, it's all tilting at windmills.
Elroy

I don't buy that "licensed 3rd parties" thing. If that was the case M$ would be the first to talk about it, even if just to shut down some voices.
They just want people to stop using it, because they want one to follow the new (and more profitable?) technologies: SaS, Web Services rentings, and the like.

Quote:

---

Originally Posted by Carlos Rocha

I don't buy that "licensed 3rd parties" thing. If that was the case M$ would be the first to talk about it, even if just to shut down some voices.
They just want people to stop using it, because they want one to follow the new (and more profitable?) technologies: SaS, Web Services rentings, and the like.

---

Well, what prevents MS from claiming just that to get rid of any headache?!

they dont want to give vb6 away because they know vb.net was a mistake.
the second the source of vb6 is out, the community will start working on it and will surpass vb.net almost immediately.
most be some stubborn old fart that is scared that vb.net is doomed if vb6 source gets out.
so the best way is to bury vb6 and hope that people forget about it, by giving out free stuff to everyone.

Not only is VB.NET a mistake, the entire .NET is a mistake, only C# is correct.

Anders Hejlsberg left Borland and joined Microsoft. He not only affected Delphi, but also affected VB6 (making VB6 dead) and .NET. He has influenced half of the world's programmers.

Quote:

---

Originally Posted by baka

they dont want to give vb6 away because they know vb.net was a mistake.
the second the source of vb6 is out, the community will start working on it and will surpass vb.net almost immediately.
most be some stubborn old fart that is scared that vb.net is doomed if vb6 source gets out.
so the best way is to bury vb6 and hope that people forget about it, by giving out free stuff to everyone.

---

Now we are talking :thumb:

Quote:

---

Originally Posted by Elroy

....
If they actually did make such an announcement, we could openly talk about how to make portable (easily copy-able) versions of the VB6 IDE, which isn't a difficult thing to do.

---

...allready done -> NanoVB

(..and I don't think MS really cares)

Quote:

---

Originally Posted by tubus

...allready done -> NanoVB

(..and I don't think MS really cares)

---

Well, that's not totally legal. And also, it doesn't cover any of the common OCX files that are often used. The way I use the VB6 IDE, it'd never be totally portable, but it could be very close. For my purposes, I would need to register (for development) a few of these OCX files.

Microsoft did distribute a VBC6.exe program (packaged as VB6CLI.exe) for a while precisely for re-registering these OCX files (for development). However, I'm not sure that program is still available. There are well known methods for getting this done, but we're again walking a fine line on exactly what's legal.

And, a point almost larger than what Microsoft cares, is what these VBForums care about.

Take Care,
Elroy

I used VB5 and VB6 since the 90s but I no longer use it professionally anymore as most projects at my job are website related. I still like to bring VB6 up every once in a while and write something needed where this is the right tool for the job but its getting less frequent.

My contribution is simple. I enjoy using VB6. I have been using it and learning it for over 10 years, my main application being a rock solid accounting suite that has never faltered. I can also knock up a file-handling utility in next to no time that is readable, instinctive and utterly bug free. In short, VB6 does everything that I want.

Quote:

---

Originally Posted by RipVoidWinkle

Every one of my .NET projects is OOP.

---

The truth of why you post this comes out about which is really just ignorance. Let me guess, do you also use hungarian notation? Do you wear "goto is bad" tshirts to impress your alumni friends?

I highly suggest you watch this video. It details a lot more than I would care to type in this reply and could be an eye-opener to you.

Object-Oriented Programming is Bad

Quote:

---

What are the (legitimate) reasons people are still using VB6 ?

---

it has paid the Bill's for the last 20 and more Years, and still provides an income

I find it very quick and easy to knock up a fully working program on Vb6 yet I only use it on very occasional basis. As a one-time fulltime developer (in QuickBasic would you believe?) I can imagine that someone who is full time involved with Vb6 for over 20 years will find it very straightforward to produce good stuff and has probably built up a good library of templates and modules.

Quote:

---

Originally Posted by el84

I find it very quick and easy to knock up a fully working program on Vb6 yet I only use it on very occasional basis. As a one-time fulltime developer (in QuickBasic would you believe?) I can imagine that someone who is full time involved with Vb6 for over 20 years will find it very straightforward to produce good stuff and has probably built up a good library of templates and modules.

---

Yep. I never really used Quick Basic much, I moved to VB for Dos instead but it was very similar to Quick Basic 4.5 just with an added visual designer and mouse support if you used the visual aspect of it. Back then I was mostly coding BBS related stuff and Door games for use with BBS systems.

Quote:

---

Originally Posted by dmaruca

The truth of why you post this comes out about which is really just ignorance. Let me guess, do you also use hungarian notation? Do you wear "goto is bad" tshirts to impress your alumni friends?

I highly suggest you watch this video. It details a lot more than I would care to type in this reply and could be an eye-opener to you.

Object-Oriented Programming is Bad

---

Well, I sat through it. The first half hour is defining the problem, the final fifteen minutes is partly not solving the problem and a few minutes describing lambdas. There were some good points, there were some bad points, but it mostly is just a person thoroughly describing the mote in his neighbors eye while never noticing the beam in his own.

If you want to believe that those views are the path to salvation, then you didn't understand his video. You may be in good company. I'm not entirely sure that he understood his own video.

Quote:

---

Originally Posted by Shaggy Hiker

There were some good points, there were some bad points, but it mostly is just a person thoroughly describing the mote in his neighbors eye while never noticing the beam in his own.

---

It's hardly an uncommon view of OOP.

As Joe Armstrong (the creator of Erlang) said...

Quote:

---

The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.

---

Armstrong summarises OOP as follows...

Quote:

---

Why OO was popular?
Reason 1 - It was thought to be easy to learn.
Reason 2 - It was thought to make code reuse easier.
Reason 3 - It was hyped.
Reason 4 - It created a new software industry.
I see no evidence of 1 and 2. Reasons 3 and 4 seem to be the driving force behind the technology. If a language technology is so bad that it creates a new industry to solve problems of its own making then it must be a good idea for the guys who want to make money.

This is is the real driving force behind OOPs

---

Why OO Sucks by Joe Armstrong

Quote:

---

Originally Posted by VB6 Programming

It's hardly an uncommon view of OOP.

As Joe Armstrong (the creator of Erlang) said...

Armstrong summarises OOP as follows...


Why OO Sucks by Joe Armstrong

---

Pfffft! That's an opinion piece... and you know what they say about opinions and what they are like....
Also it smells of a "omg elrang is so fraking awesome and everything else is garbage in comparison" piece...
It's slanted with no real backing. At least that's my opinion, because well like opinions, I have one too, and sometimes I can be one.

-tg

Quote:

---

Originally Posted by techgnome

Pfffft! That's an opinion piece... and you know what they say about opinions and what they are like....
-tg

---

Sure. Criticising OOP is rather like swearing in church.

But nailing your opinions to the church door has been known to work.

My 2 cents regarding the "OOP-bashing"...

- Classes are useful (period)...
- Class-Events (to let Class-Instances easily interact with each other) even more so...
- languages which do not support these two concepts "out of the box" have disadvantages with GUI-development

So - IMO there's nothing really wrong with OOP-concepts ...
(they are useful, when not "over-done" - as always ... it's the right mix, which has to be found)

What's wrong is "evangelists, with over-puristic, narrow-minded views" as e.g.
- only procedural (or functional) programming is good
- or, only a pure OOP-paradigm is the "real deal" (along with: "everything is an Object")

We should be thankful, that VB6 is a language, which allows free choice with regards to the amount of "procedural + OOPish mixing".

BTW, what I find funny is, how OOP-purists have now finally found, that: "inheritance is bad for your class-hierarchies, try to avoid it".
Many in that camp still claiming though: "VB6 is not a full OOP-language" - because "VB6-Classes miss inheritance".
<sigh>

Olaf

Quote:

---

Originally Posted by dmaruca

The truth of why you post this comes out about which is really just ignorance. Let me guess, do you also use hungarian notation? Do you wear "goto is bad" tshirts to impress your alumni friends?

I highly suggest you watch this video. It details a lot more than I would care to type in this reply and could be an eye-opener to you.

Object-Oriented Programming is Bad

---

well I watched about half of the video, without seeing an actual Program from
the Guy and his concepts ??? who knows what the thing is going to look like.
perhaps he will find his way around, but definitely not a Group of Programmers

Seems like there are a lot of people talking about OOP now. I wasn't trying to derail the thread, but it appears the original poster only pointed out that OOP was his beef with VB6, so that's why I brought it up to respond to him. I've watched a number of the videos that the guy I linked to made. Sorry for any confusion in the point I was trying to get across. I may have been combining memories from multiple videos in my mind. I'm actually amazed that people watched it. I've never had people watch a video I've linked before lol.

Brian argues, and I agree, that pure 100% OOP doesn't really solve anything and creates more problems than it tries to solve. Basically his argument goes something like this: There is a problem and the OOP programmer daydreams for a while and comes up with Objects A and B which perform tasks and are called by a routine. Both objects perform tasks related to the needs of the software, but are now sectioned off from each other. The concept sounds great, but often falls apart once it grows bigger. The needs of the software change and A and B may not conceptually fit the needs of the data or task any longer. What could be a simple fix in a procedural setup now clash with the self-documenting and understood meaning of what A or B were originally created to do. Now the objects must be modified differently from their understood English meaning to be different. For example, Object A could be a DataReader which is understood to only read data in a specific file format. The programmer later discovers that he could get a lot of speed increase by skipping rows during import which aren't relevant instead of reading everything in and filtering it later (duh). Now, DataReader become DataReaderAndFilter? Or maybe create a new filter class and pass that in. Later the programmer discovers he could speed it up more if he maintains some global file position pointers to maintain read state and only reads part of the data, does some checks, and continues or quits based on some logic. This logic is done in object B since that is where it was originally put. Now the code execution bounces between Objects A and B and is quickly becoming harder to follow and understand than if it were not OOP. I guess now the programmer would create a filter class and another class to hold the file state. To me, this is quickly becoming procedural code that is mucked up by some high school OOP junk.

I see this kind of stuff all the time at work. Often people spend more time trying to create some glorious setup which objects try to fit the charts shows to management and project managers than they do just getting the work done. It's a house of cards and wastes time. They spend more time trying to figure out how to elegantly put things into the objects (which never happens) than just getting it done.

Anyways, this is longer than I wanted to type and I didn't mean to get caught up in any debate which would better fit a blog post. I hope you all have a good Christmas.

Quote:

---

Originally Posted by Schmidt

What's wrong is "evangelists, with over-puristic, narrow-minded views" as e.g.
- only procedural (or functional) programming is good
- or, only a pure OOP-paradigm is the "real deal" (along with: "everything is an Object")

---

Agreed. My earlier remarks were against the crowd in #2 that you spoke of.

You blokes can argue yourself senseless if you like. I need a job done so I do it with Vb6 (sometimes with a little help here) and don't try to tie myself into intellectual knots or brood over becoming (or beating) any code snob. I have not yet come across a single thing that Vb6 can't do. I've only ever noticed one shortcoming and that is that setting up a colour gradient for a form is a little more convoluted than with .NET. And that is hardly of earth-shattering importance. Probably I lack intellectual rigour, but to me programming is a tool to get everyday things done and not an end unto itself. Oh and Happy Christmas to those who have helped me in the past, even to that person who appears to have deliberately sent obfuscated stuff to illustrate my ignorance, and in fact to everyone. Cheers (raises glass...).

Through the years, I've been all over the place on this OOP debate. And, truth be told, I agree with much that the "Why OO Sucks" article says, but not all of it.

The one claim that stuck in my craw was that "Data structure and functions should not be bound together". I think that wholly depends on the situation.

A few different things come to mind. One is a questionnaire program that I was involved with years ago. The program attempted to be a completely general purpose program for developing and administering questionnaires. I suppose you could think "Survey Monkey" but specific to Windows PCs. Now, in my work, we always use these standardized/validated questionnaires that can't be tampered with. And sometimes, the questions are asked in rather bizarre ways, but again, we can't tamper. Therefore, we were constantly going back to the developers to make their program even more flexible. And they never really got things completely right.

But the biggest flop in that whole endeavor was the ability to query results (or lack thereof). First, many of these questionnaires were "scored", and that's a lot of the reason we kept having to go back to the developers. However, their database fields were completely generic names (like Field1, Field2, etc), making it very difficult to develop useful queries. Now, I was dealing with very smart people (MDs and PhDs), but they didn't necessarily know how to perform a MS-Access SQL query all that well. They could muddle through, but not when things got too complex. Therefore, the total obscurity of the database structure naming was ultimately its complete downfall.

Since that time (back in the early 2000s), I've re-developed all of our questionnaires into tables with much more explicit names. Here's a table specific to a questionnaire known as PODCI. There are two tables, but this one just includes the "Scores":

Attachment 164233

And here's a PubMed search of several published studies using this PODCI questionnaire, and I can promise that a great many of these used data from my program (as there's really not another one out there that collects PODCI on a computer):

Attachment 164235

And that's just one out of fourteen different questionnaires administered by the program.

So, I'm clearly not an advocate of total generalization. Ultimately, all end-user programs must get down to specifics. And, if the users are going to get involved in data queries, that would also involve the actual database structure.

However, let me return to the OOP debate. My main program has grown to be quite large through the years. And, as such, I've got sub-groupings within each module type. Let's focus just on class (CLS) modules. Here's a screenshot of a few of my classes:

Attachment 164237

As can be seen, I have some cls_Gen_... modules and I also have other cls... modules. The cls_Gen_... modules are quite general, and could be (and often are) pulled into completely unrelated programs. However, the others are all rather specific to my primary program, and often have elements of "data structure" within them. Here's just a small snippet out of one of those cls... specific modules:

Code:

---


    lInc p: mlParamRow(p) = 69:    msParamFn(p) = "GcdFileName":                                msParamDesc(p) = "GCD File Name":                                          msParamCol(p) = "A":    mbbParamFont(p) = 2: mbbParamNoFn(p) = 1: mbbParamAtypical(p) = 1: mbbParamIsString(p) = 1: mbbParamFmtCode(p) = 1
    lInc p: mlParamRow(p) = 70:    msParamFn(p) = "TheSide":                                    msParamDesc(p) = "The Side":                                              msParamCol(p) = "B":                        mbbParamNoFn(p) = 1: mbbParamAtypical(p) = 1: mbbParamIsString(p) = 1: mbbParamFmtCode(p) = 1
    lInc p: mlParamRow(p) = 71:    msParamFn(p) = "StanceDurationPct":                          msParamDesc(p) = "Stance Duration % of Cycle":                            msParamCol(p) = "IK":                                            mbbParamAtypical(p) = 1:                          mbbParamFmtCode(p) = 3: mbbParamSpcTmp(p) = 1: mbbParamSpcTmpPct(p) = 1
    lInc p: mlParamRow(p) = 72:    msParamFn(p) = "CadenceStride":                              msParamDesc(p) = "Cadence (Stride)":                                      msParamCol(p) = "G":    mbbParamFont(p) = 1:                      mbbParamAtypical(p) = 1:                                                  mbbParamSpcTmp(p) = 1
    lInc p: mlParamRow(p) = 83:    msParamFn(p) = "CadenceStep":                                msParamDesc(p) = "Cadence (Step)":                                        msParamCol(p) = "R":    mbbParamFont(p) = 1:                      mbbParamAtypical(p) = 1:                          mbbParamFmtCode(p) = 4: mbbParamSpcTmp(p) = 1
    lInc p: mlParamRow(p) = 73:    msParamFn(p) = "WalkingSpeed":                              msParamDesc(p) = "Walking Speed":                                          msParamCol(p) = "H":                                              mbbParamAtypical(p) = 1:                          mbbParamFmtCode(p) = 2: mbbParamSpcTmp(p) = 1
    lInc p: mlParamRow(p) = 74:    msParamFn(p) = "StrideTime":                                msParamDesc(p) = "Stride Time (secs)":                                    msParamCol(p) = "I":                                              mbbParamAtypical(p) = 1:                          mbbParamFmtCode(p) = 2: mbbParamSpcTmp(p) = 1
    lInc p: mlParamRow(p) = 75:    msParamFn(p) = "StepTimePercent":                            msParamDesc(p) = "Step Time % of Cycle":                                  msParamCol(p) = "J":                                              mbbParamAtypical(p) = 1:                          mbbParamFmtCode(p) = 3: mbbParamSpcTmp(p) = 1: mbbParamSpcTmpPct(p) = 1
    lInc p: mlParamRow(p) = 76:    msParamFn(p) = "SingleSupportPct":                          msParamDesc(p) = "Single Support % of Cycle":                              msParamCol(p) = "K":                                              mbbParamAtypical(p) = 1:                          mbbParamFmtCode(p) = 3: mbbParamSpcTmp(p) = 1: mbbParamSpcTmpPct(p) = 1
    lInc p: mlParamRow(p) = 77:    msParamFn(p) = "DoubleSupportPct":                          msParamDesc(p) = "Double Support % of Cycle":                              msParamCol(p) = "L":                                              mbbParamAtypical(p) = 1:                          mbbParamFmtCode(p) = 3: mbbParamSpcTmp(p) = 1: mbbParamSpcTmpPct(p) = 1
    lInc p: mlParamRow(p) = 78:    msParamFn(p) = "StrideLength":                              msParamDesc(p) = "Stride Length":                                          msParamCol(p) = "M":                                              mbbParamAtypical(p) = 1:                          mbbParamFmtCode(p) = 2: mbbParamSpcTmp(p) = 1
    lInc p: mlParamRow(p) = 79:    msParamFn(p) = "StepLength":                                msParamDesc(p) = "Step Length":                                            msParamCol(p) = "N":                                              mbbParamAtypical(p) = 1:                          mbbParamFmtCode(p) = 2: mbbParamSpcTmp(p) = 1
    lInc p: mlParamRow(p) = 80:    msParamFn(p) = "TimePctToOppositeFootOff":                  msParamDesc(p) = "Time % To Opposite Off":                                msParamCol(p) = "O":                                              mbbParamAtypical(p) = 1:                          mbbParamFmtCode(p) = 3: mbbParamSpcTmp(p) = 1: mbbParamSpcTmpPct(p) = 1
    lInc p: mlParamRow(p) = 81:    msParamFn(p) = "TimePctToOppositeFootStrike":                msParamDesc(p) = "Time % To Opposite Strike":                              msParamCol(p) = "P":                                              mbbParamAtypical(p) = 1:                          mbbParamFmtCode(p) = 3: mbbParamSpcTmp(p) = 1: mbbParamSpcTmpPct(p) = 1
    lInc p: mlParamRow(p) = 82:    msParamFn(p) = "TimePctToSameFootOff":                      msParamDesc(p) = "Time % To Same Off":                                    msParamCol(p) = "Q":                                              mbbParamAtypical(p) = 1:                          mbbParamFmtCode(p) = 3: mbbParamSpcTmp(p) = 1: mbbParamSpcTmpPct(p) = 1
    '
    lInc p: mlParamRow(p) = 375:    msParamFn(p) = "GcdBodyMass":                                msParamDesc(p) = "Body Mass from C3D":                                    msParamCol(p) = "IM":                                            mbbParamAtypical(p) = 1:                                                                                                  mbbParamC3dScalar(p) = 1
    lInc p: mlParamRow(p) = 376:    msParamFn(p) = "GcdHeight":                                  msParamDesc(p) = "Height from C3D":                                        msParamCol(p) = "IN":                                            mbbParamAtypical(p) = 1:                          mbbParamFmtCode(p) = 4:                                                  mbbParamC3dScalar(p) = 1
    lInc p: mlParamRow(p) = 377:    msParamFn(p) = "GcdInterAsisDistance":                      msParamDesc(p) = "Inter Asis Distance from C3D":                          msParamCol(p) = "IO":                                            mbbParamAtypical(p) = 1:                          mbbParamFmtCode(p) = 4:                                                  mbbParamC3dScalar(p) = 1
    lInc p: mlParamRow(p) = 378:    msParamFn(p) = "GcdHipWidth":                                msParamDesc(p) = "Hip Width from C3D":                                    msParamCol(p) = "IP":                                            mbbParamAtypical(p) = 1:                          mbbParamFmtCode(p) = 4:                                                  mbbParamC3dScalar(p) = 1
    lInc p: mlParamRow(p) = 379:    msParamFn(p) = "GcdSameLegLength":                          msParamDesc(p) = "Same Leg Length from C3D":                              msParamCol(p) = "IQ":                                            mbbParamAtypical(p) = 1:                          mbbParamFmtCode(p) = 4:                                                  mbbParamC3dScalar(p) = 1
    lInc p: mlParamRow(p) = 380:    msParamFn(p) = "GcdOppLegLength":                            msParamDesc(p) = "Opp Leg Length from C3D":                                msParamCol(p) = "IR":                                            mbbParamAtypical(p) = 1:                          mbbParamFmtCode(p) = 4:                                                  mbbParamC3dScalar(p) = 1
    lInc p: mlParamRow(p) = 381:    msParamFn(p) = "GcdSameAsisTrocanterDistance":              msParamDesc(p) = "Same Asis Trocanter Distance from C3D":                  msParamCol(p) = "IS":                                            mbbParamAtypical(p) = 1:                                                                                                  mbbParamC3dScalar(p) = 1
    lInc p: mlParamRow(p) = 382:    msParamFn(p) = "GcdOppAsisTrocanterDistance":                msParamDesc(p) = "Opp Asis Trocanter Distance from C3D":                  msParamCol(p) = "IT":                                            mbbParamAtypical(p) = 1:                                                                                                  mbbParamC3dScalar(p) = 1



---

It's clear to see that that code is quite specific to data structure, and I'm quite fine with it being in a class module. That module has all kinds of cross-reference functions quite useful in getting all kinds of tasks done. And it closely maps the database tables where data are stored.

So, for a comprehensive end-user program, I think it comes down to the KISS principal. Let's just take the approach that attempts to keep the code as simple as possible, regardless of whether that involves functions, classes, methods, or some combination of all the above.

Merry Christmas,
Elroy

Thinking back on the simple programs I have written, they are essentially procedural. Technically, since I'm using VB.NET, they can't REALLY be procedural, if you want to be pedantic, since everything is in a class in .NET. Still, I don't get bogged down with being a purist. I've seen people go overboard with class hierarchies. It gets ugly. Still, I don't think that's a problem with OO, I think that's a problem with the person writing the thing.

I'm also working on a project that could be called, "Embarrassingly Object Oriented" following the lead of the term "Embarrassingly Parallel". An Embarrassingly Object Oriented project is one where the objects are so bloody obvious they pretty much couldn't be anything else. It's not even clear to see how it could be procedural. It's one of those projects that people suspect don't really exist. Most LOB applications deal with abstract, fuzzy, concepts that they try to fit into an OO straitjacket. In this case, I'm dealing with a fish hatchery. It doesn't get any more concrete than that...since hatcheries tend to be mostly concrete. The objects are as obvious as controls on a form.

However, situations like that are vanishingly rare. What I'd say it comes down to is that when a person is starting out, they may seek out a master to teach them the "true path" to programming. The problem is, there isn't a true path. For most destinations, there are many ways you can get there, though there may be a BEST way in certain circumstances. When starting out, it generally isn't very helpful to hear, "do what you want, there are many paths, and none can know the best one for any particular case." So, they tend to seek some ultimate truth. Once you get more advanced, any ultimate truth proves to be just one perspective.

i have learned mostly by myself, trial and error and of course writing code from a magazine and eventually using the internet, and i learn a lot from here, even if i was "late" to join here.
when i started using vb6, i followed a more "dos" way, as i was used to turbo pascal. more direct programming, no classes and very little use of any ocx.
but a couple of years ago (yes quite late), i decided to try classes, and after a couple of projects, and lastly a quite large project, i noticed its more disadvantages than advantages.
so, 5 months ago i redid the whole project, without using classes, as i wonder, why should i do that when its not really "how" i do programming.
dilettante has wrote quite a lot of times, why i use vb6 at all, as i dont like to use the default components. and this is important, why not?
my "ultimate truth" is to be able to make something my way, in a way that i understand and feel right.
sure, its not that i create everything myself, i use snippets from everywhere, but i build it up my way. i change it so that i fit my style, it may be imperfect for everyone else but its perfect for me.

so even if Olaf is giving me perfect solution, a perfect rc5/cairo to do everything better, its still not me, its his puppy not mine.
i want to "create", not "copy" and for me to create i need to do it my way, the way it feel right and the way i can understand.

[...]

Quote:

---

I really like only having to declare the variable and having it automatically initialized to a sane default value.

---

I really like the way Vb.Net does it. When you want anything other than the default value it is quicker to type and is always a little bit more readable.

For example

Code:

---

Dim MyString as String="SomeText"
Dim MyInt as Int32=14

---

Where as in VB6 you would need

Code:

---

Dim MyString as String: MyString="SomeText"
Dim MyInt as Long: MyInt=14

---

Or

Code:

---

Dim MyString as String
MyString="SomeText"
Dim MyInt as Long
MyInt=14

---

I am glad the topic somewhat shifted to OOP, mainly because it is a common argument for the reason we should move to .net.

I struggled with understanding OOP for many years, mainly the inheritance part. The whole inheritance thing totally did not compute in my brain, it did not make sense to me to put in concrete structure of my programs in what felt like very odd ways of building hierarchies which really are not natural to the way I solve problems.

In recent years I have come to terms that I was not the only one that felt this way about inheritance, and in fact some very wise people concur. The way that fits better for me is object composition, instead of using inheritance, using objects/classes as building blocks. It is much more flexible to change, and the more I use this technique the more I see first hand that changes and maintenance is much easier for me.

To back this up even more, about 15+ years ago I used to work with java-oop disciples. I met with them several years later to ask them what they have learned over the years, the answer was unanimous from all of them. There is no one way to solve software problems and their fanatical approach to OOP was not effective in the long run.

So in conclusion, just as in life, using multiple techniques to include OOP, procedural, functional and all hybrids in between gets the best results in software design. The argument that somehow if we move to .net and now were able to use inheritance, our software will be better is not true, so in the end moving to .net does not have any benefit in my mind.

The way I am reading it the main aspect of OOP is the ability to add events to the objects.
For example, it is very powerful to access the object model of Visual Basic for Applications 6.5.
I can't see making a VB6 IDE efficiently using just procedural programming with a continuous poll.

Quote:

---

Originally Posted by axisdj

The argument that somehow if we move to .net and now were able to use inheritance, our software will be better is not true, so in the end moving to .net does not have any benefit in my mind.

---

Did anybody really make THAT argument? I guess I do use inheritance, especially with controls, but it's probably less than 5% of classes, and possibly less than 1% of classes that I bother with inheriting...except that every form inherits from a base class, so there's that, but when it comes to inheritance that I create, that's REALLY minimal. Inheritance is not a good reason to move...to anything. Runtime polymorphism is really cool. Almost totally useless, but really cool. You have to struggle to find a place where it even makes sense as an alternative, and only a minority of those cases are such that it makes more sense than any other approach. However, inheritance can be abused like crazy. It's probably the biggest, single, problem with OO. People see inheritance, and if they "get it" to some degree....they tend to go hog wild. They don't go hog wild with runtime polymorphism because it applies to rarely, but inheritance could apply ANYWHERE, if you wanted it to, which is just too intoxicating at times.

@baka: I don't know the words, but I heard Sinatra singing when I read your post. You could probably re-write "My Way" to cover that entire post. The refrain would be "I code it myyyyyyyyyy way!" You could even add in that comment about Olaf, since Olaf is a pretty mellifluous name.

Quote:

---

Originally Posted by TTn

The way I am reading it the main aspect of OOP is the ability to add events to the objects.
For example, it is very powerful to access the object model of Visual Basic for Applications 6.5.
I can't see making a VB6 IDE efficiently using just procedural programming with a continuous poll.

---

Are there either Delegates or function pointers in VB6? Those two are the same thing, really, and if they exist in VB6, then they likely wouldn't have either of those names, but I don't recall if there was anything like them.

That's all you need for the event model. The object would hold an array of delegates. When it "raised the event", all it would do is iterate through the array calling each delegate found there. That does require that you be able to pass function pointers around, though. It really has nothing much to do with OO, because the rest of the mechanism is already available. What happens in .NET is that the structure of that "array of delegates" is hidden, and there are a couple means to add functions into the array, but that's pretty much syntactical sugar. You couldn't do EXACTLY that, but you could get kind of close.

On the other hand, in VB6, the event mechanism would tend to be 'leaky', because it would be very accessible to the coder. They could directly mess with the array of delegates in bad ways, or directly mess with the implementation of the "event raising" in ways that would make for inconsistent behavior between different types.

Quote:

---

Originally Posted by Shaggy Hiker

Are there either Delegates or function pointers in VB6? ...
The object would hold an array of delegates.
When it "raised the event", all it would do is iterate through the array calling each delegate found there.

---

VB6 does something similar (hidden under the covers) -
it's only that the Event-Raising-Object is offering a kind of "Subscriber-Collection" (allowing for more than a single Event-Listener),
so it does not only hold "an array of function-pointers", but instead (somewhat simplified) is working this way:
- one or more interested subscriber-instances are added into the subscribers-collection of the Event-Raising-Object (e.g. a Form adds itself into the Subscribers-Collection of a CommandButton)
- (the compiler "knows" when a parent- or handler-object "needs to be added" by looking at the parents WithEvents Variables (WithEvents == "This Child-Variable offers A Subscribers-Collection" I can myself add into).
- each of those subscriber-instances then containing the complete VTable (of function-pointers) for the whole Event-Interface the Sender-Object has to offer

If the Object in question (e.g. the CommandButton) raises an Event, it does basically (somewhat simplified again) the following:

Code:

---

  For Each Subscriber In Me.EventSubscribersCol
    CallByName Subscriber, TheEventName, vbMethod, TheEventParams
  Next

---

CallByName (DispInvoke) then acting as the generic mechanism, which resolves from the EventName (or -ID),
to the (EventHandler-) function-pointer in the VTable of each registered EventHandler-instance.

Olaf

Right. The mechanism is essentially the same for everybody. I oversimplified, because I focused on the function pointer, when the instance is also necessary, but that part is relatively easy. What I don't know is whether or not a function pointer can be created in VB6. You point out what is happening "hidden under the covers", but if a person wanted to do that on top of the covers, they can deal with instances easily enough (subscribers), so if there can be created a function pointer in VB6, then you can make your own event handler that can behave in a similar fashion to the built in options.

What you probably wouldn't be able to do is make something that worked like WithEvents, cause that has some very peculiar behaviors. Still, you could create something essentially the same as AddHandler/RemoveHandler.

My point was that TTn was saying that adding events to the object was a powerful feature of OO. If delegates are available, then that powerful feature is not just for OO.

Quote:

---

Originally Posted by Shaggy Hiker

My point was that TTn was saying that adding events to the object was a powerful feature of OO.
If delegates are available, then that powerful feature is not just for OO.

---

Sure - if you want to break it down to "passing a single function pointer"
(instead of "a specific, ordered set of function-pointers" - as e.g. present in an objects VTable) -
then VB6 can deal with that as well.

For example "Flat-Callback-routines" (as required by some APIs which expect Pointers to such functions)
are a quite common concept with (usually C-implemented) flat-API-libs (dozens of examples in the Win32-API).
VB6 can address these libs, providing the FuncPtr using -> AddressOf (VB6-defined Module-function).

If we work "within our own space" (with VB6-Classes and -Controls), we don't need this approach though.
The more typesafe approach is, to pass a CallbackObject-Instance which adheres to a specific ClassType-interface
(instead of passing a single Function, which adheres to a certain Function-signature).

If the specific Interface of the Callback-Class contains only a single Function - so be it...
and if you pass such a Callback-instance along (instead of the direct Function-Pointer) -
performance-wise the difference is just in a single layer of indirection - just a single "Pointer-Dereferencing-Step" away
(since an ObjPtr is a Pointer to the pVTable Member of the Objects "This"-struct - and pVTable resolves directly to the "first Obj-Method").

E.g. the COM-based WebBrowser-Object (the .NET-Browser-control is only an extra-wrapper around this COM-instance),
accepts VB6-provided COM-Class-instances which have a single "Dispatch-Default-Method" defined in them,
as CallBack-Delegates which can be bound directly to e.g. an HTML-TextInput-Elements "onchange"-handler-slot.

This might serve as another example, that "Callback-Delegates" are not really new, or a ".NET-invention".

Olaf

Yes, the term delegate is used in .NET to represent this. For example after converting a VB6 project, you will often have to hook up a delegate.
I believe in earlier versions of Visual Basic you had to use a form to represent a window-less class that had event abilities. This was before VB became mostly OOP, event driven.
The term "proxy method/function" was used to wrap up any event raising in one place, just in case you might want to add parameters to be handled. Parameters that can include objects.

Here is the basic idea, in case I was not clear.

Code:

---

Public Event ClickEvent()

Private Sub Command1_Click()
    RaiseEvent ClickEvent
End Sub

---

Code:

---

Private WithEvents Foo As Form1

Private Sub Form_Load()
    'initialise the object
    Set Foo = New Form1
    'show the Form1 object which has the button on so we have something to click
    Foo.Show
End Sub

'when the button is clicked this event is raised
Private Sub Foo_ClickEvent()
    MsgBox "Click Event"
End Sub

---

Here is a decent little article on the subject.
https://www.developer.com/net/vb/art...al-Basic-6.htm

Quote:

---

By adding the WithEvents keyword all of the events declared in Class1 will show up in the code editor in VB6

---

Quote:

---

As you may already know, events are called delegates in Visual Basic .NET and take on a new role, including being at the center of the multithreading model in Visual Basic .NET.

---

I think you may be misremembering things. That article is terrible, clarifies nothing, misstates much, and makes poor recommendations. I'm still laughing.

Quote:

---

Originally Posted by RipVoidWinkle

I professionally used VB6 in around 1998.
I kept using it as a hobbyist into the early 2000s.

This forum is very active.
I'm very curious who is still coding with VB6 .....20 years later.
Novelty or production programming fixes?

Most places I worked for were obsessed with rewriting the code base.
Are you guys working for firms that are the opposite?
They refuse to budget for a rewrite, and your supporting 20 year old code?

---

I'm on the second half of a thirty plus year career. It seems the first half people asked these very same questions about COBOL. The answers are pretty much the same :p

https://freedomafterthesharks.com/20...anguage-in-it/

Quote:

---

Originally Posted by dilettante

I think you may be misremembering things. That article is terrible, clarifies nothing, misstates much, and makes poor recommendations. I'm still laughing.

---

Do you care to elaborate about what I misremembered? Several books indicate this was true.

I'm not sure what version was the first that allowed developers to add custom event handlers to class objects. A couple of the MS press books indicate that this really was a turning point towards OOP.

I was clarifying to Shaggy that we can use the "WithEvents" keyword with the instance. It seemed as though he wasn't sure if that was possible, but perhaps I misunderstood his question.

As far as Paul Kimmel's article, well....he is highly respected as a book author and article writer, so you will have to explain your contention in some detail.