04131408.txt 13-Apr-00 Life Imitates Art Or VB imitates VO. Micro$haft have announced that the next version of VB will (finally) include full OOP technology. Inheritance, encapsulation, ploymorphism, overloading, free threading, and structured error handling are just some of the features that have been mentioned. Now VBers can learn about some of what we've been doing for years. :) http://msdn.microsoft.com/vstudio/nextgen/ Has the details. Enjoy -- g. Gary Stark gstark@RedbacksWeb.com http://RedbacksWeb.com I've worked at a couple of companies that use VB and honestly, I have never seen a nice VB app. On the other hand, I've seen some very impressive VO and Delphi apps. Of the VB apps that I've looked at, performance has been very slow and the apps don't look and feel at all professional. I would imagine that this is not the case with apps developed by expert VB programmers. Since you develop using both products, can you tell me if in VB one can develop professional looking/performing software? Please pardon my ignorance Gary. I would appreciate your comments. Fernie Fernie, I can answer that one for Gary. I use VB regularly for Clients (since many of mine are corporates...etc and I have little choice on the tool). IAC, Yes, its feasible to create a professional, robust, stable and fast VB app. However, it requires the following: - Proper time devoted to analysis and design. Gee, this may seem like a no-brainer, but the problem with the VB marketing is that all the "dabblers" think that the wizards will create all of this for you automatically. WRONG - Proper time devotes to class designs. VB doesn't have real inheritance, which requires some massaging of "ideal" designs to cope. Most often you have a lot of related classes, which contain a LOT of duplicated or redundant code to get the desired behaviour. It works well, but takes time to debug as a result. - Error handling. This is the one are that VB is, without a doubt, piss-poor on. Error code has to be placed EVERYWHERE if you want an app to be even partially stable. Strict adherance to design and coding standards is essential here. Gee, no wonder that it isn't done. - Speed. Actually, VB 6.0 isn't too bad. Yes, It won't beat VO or VC++ in a shoot out, but it ain't bad for even large db apps. The problem is that the standard wizards...etc for VB data access don't scale well, and you have to know a lot about the database concerned, plan and design all acess carefully, and do a lot of load testing to ensure there are no bottlenecks. This is especially interesting with Access/JET. the fastest way to code a JET system (using MDB files) is to code in the old Clipper 3GL fashion (eg: SEEK everything). This is TOTALLY against all the rules documented for both VB and Access, but its true - you get 5 fold speed increases! - Server databases aren't so much an isues here, except to say that the (in)experience of the average VB programmer can cause problems, as they expect wizards to solve everything. - Its interesting how the VB journals come back to the topic of "algorithms" regularly, as though its a new concept. They highlight a problem - people for whom VB is their first and only language generally don't have skills in "coding their way out of a hole", to use a favourite expression of mine. But then, my opinion is that you are a better analyst/designer/programmer if you have worked on several environments - as you can solve problems by drawing on a wider range of experiences. - ActiveX and DLL Hell. Because MS insists on hooking everything in VB to ActiveX (all its own classes are actually ActiveX internally), distribution is problemmatic. To be fair, this isn't so much VB's problem, as MS's when they continually issue updates to key subsystems inside things like Ofice and IE (which then break previously working code elsewhere!). I think you can see the theme of my diatribe here . Those who know me will recognise this rant, and I go off on it regularly . In summary, VB makes it extraordinarily easy to make a BAD program really quickly. This is its primary weakness - and the weakness of all the marketing strategies, which encourage programmers to build huge things without any methodology. This is a constant no matter what programming langauge is being used. Shops that have rigorous analysis/design/coding methodology, and proper project management (no matter what project model they use) and deep experience generally succeed. those that don't have this either create garbage, or don't create anything at all. Getting back to the VO:VB question. While The next version of VB will bring it up to par on a number of technical points, IMO the most important difference remains the experience and skill of the developer and the wider project team. I think VO lends itself to this more, simply because it doesn't pull any punches - it immediately says you have to know what you are about if you want to build a VO system. If you haven't done your analysis/design, then you get into a hole very quickly, instead of later. Our community went through this phase change several years back when Clipper 5.0 first introduced objects. there was a LOT of fallout over this issue, and the result was that the clipper community became one of professionals only - the dabblers couldn't handle the newer concepts (which made quick and dirty code difficult to use on a large scale) and left. The dBase IV product never went anywhere because they attempted to keep both groups - the dabblers and professionals, without getting anywhere fast. VB suffers from the same problem - its made up of a LOT of dabblers and a small cadre of professionals - and MS is struggling to satisfy both. Lastly, since VO is written using itself. That is, the class library we use to build apps is all VO code. We have an very internally consistent and extensible environment to program in (much like the Delphi model). The benefits for systems design cannot be underestimated here. VB contains so many "internals" and "don't go here" stuff that coding a generic system is a joke sometimes, as you are faced with many inconsistencies, objects you can use one way and not another,...etc. seeya...Pete Peter Fallon www.castlesoftware.com.au Hi Peter, > - Error handling. This is the one are that VB is, without a doubt, piss-poor on. Error code has to be placed EVERYWHERE if you want an app to be even partially stable. > Is't like this? Private Function GetUserID() As String Dim sUserName As String * 255 Dim lSuccess As Long Dim lErrNo As Long Dim sErrSource As String Dim sErrDesc As String Dim lLength As Long On Error GoTo ErrHandler lLength = Len(sUserName) lSuccess = GetUserName(sUserName, lLength) GetUserID = Left(sUserName, lLength) Exit Function ErrHandler: lErrNo = Err.Number sErrSource = Err.Source sErrDesc = Err.Description Err.Raise lErrNo, cModuleName & ".GetWorkStationID>>" & sErrSource, sErrDesc End Function This is equivalent in VO: METHOD cGetUserName() AS STRING PASCAL CLASS HRSysInfo LOCAL DIM abBuffer[MAX_COMPUTERNAME_LENGTH + 1] AS BYTE LOCAL dwSize AS DWORD, cGetUserName AS STRING dwSize:=MAX_COMPUTERNAME_LENGTH + 1 HRError{}:vAssert(GetUserName(@abBuffer, @dwSize), ; "GetUserName", {}) // Exact equivalent with VB code above should be: // GetUserName(@abBuffer, @dwSize) // But I want to handle the case when GetUserName fail // in VO cGetUserName:=Mem2String(@abBuffer, dwSize-1) RETURN (cGetUserName) In VO error handler can be customize, in error handler we just simply log down the information we think which are useful, and this is a one time job and transparent to other programmer who use our error handler. Since error are automatically handle by error handler, we can achieve same result(even better result) with lesser code compare with VB. This is why I choose VO for big project, this will save a lot of time on programming and debugging, less code less bug! :-) Regards, Wong Wong, >Is't like this? thats correct, but not the half of it. Vb, as you showed, still uses a GOTO to execute error code, interrupt style. However, what this doesn't show is that this error routine will be called by any error, even if its in a nested call somehere - but the error routine will not know this. There is no way with straight VB to get a call tree, or to resume at the exact point of error in a nested routine. VB has no application wide error handler - which is why you have to put error code everywhere (and I Mean everywhere!!). There is no concept of "ownership", whereby an error in an event will be passed to the containing window...etc. To cope with the above, I have a standard block of error logging and handling code (about 20 lines) that goes in most events, functions and routines. In a large system of several dozen objects, each with a dozen or so eents, methods...etc, several dozen forms with dozens of event each - you do the math on the amount of redundant code that makes for...All absolutely essential for a robust system, one that picks up after itself, and logs every problem in full to you can trace the error later. Only the error handlers in Delphi are on par with those in VO. Its one of the BIG black marks again MS for allowing such a poor state of technology to remain in something as "mature" as VB. I once asked an MS bloke whether this would be fixed (back before VB 5 was released), and he indicated that in MS's view, if you wanted to code professionally, you should be using VC++. Obviously with the announcement Gary highlighted, this point of view has changed, but its only taken them how many years?? seeya...Pete Peter Fallon www.castlesoftware.com.au Hi Peter, I'm not familiar with VB, and I'm also not good at designing compiler and programming language architechture, but in my impression of the existing VB language architecture, it can't support full OOP feature seamlessly, in other word, the new OOP support will not backward compatible with existing VB code, do you think so? Regards, Wong Wong, No, the reason VB couldn't support inheritance till now is that ALL VB objects, internals, the one you write yourself...etc are all COM objects. That is, the windows ActiveX/OLE engine is behind all instantiation, control, method passing...etc. The whole schebang. The VB language is limited by the COM engine only. As you know, COM didn't support inheritance till COM+ in Win2K. In fact, when you examine all of the new object features advertised for the next version of VB, they are simply the VB versions of all the new features in COM+. Nothing more, nothing less. Its this linkage which leads me to suspect that VB may be more tightly bound to Win2K than I'd like. I hope MS allows us to use these new features on Win9x and NT 4.0, otherwise they'll be useless. MS writes a LOT about the whys and wherefores of the feature selection in prior versions of VB - and its a real laugh, for anyone who has used say VO, Delphi or C++ - since the reason given for the limits of VB are nothing but rubbish - apart from the obvious assertion that COM is slow. Back in VB 4.0, MS made the choice to bind the product tightly to their COM engine. This means its piss easy in VB to make COM objects like controls, ActiveX servers...etc. But of course its limited to only those things COM supports - and so the language wasn't as rich as it should have been. On the reverse side - its also why using COM is a bitch for other language products, as you have to denigrate the richness of the language you have in order to satisfy COM requirements! seeya...Pete Peter Fallon www.castlesoftware.com.au Hi Peter, Before Chinese New Year, a software vendor invited me to joint their banking software project, but for marketing reason they choose VB as their development tool. Thanks for your information, now I'm firmed, if they not going to change their tool, I will not going to joint them. Somehow money are not the most important thing to me, I'm more toward to come out the product I will proud of. As long as company still can making money! Thanks, Wong > No, the reason VB couldn't support inheritance till now is that ALL VB objects, internals, the one you write yourself...etc are all COM objects. > So there must be pretty huge overhead code, right? Pavel Pavel, >So there must be pretty huge overhead code, right? Not so much overheads, although the VB runtime is now 1.8M+ (that befreo you add data manipulation dependencies). More that its extremely sensitive to the OLE environment and general OCX/DLL environment on a destination PC. I've had obsure problems with installs that were only fixed when the PC was wiped, and windows (95 or 98) reinstalled from scratch. Despite having carefully checked the version numbers of the declared dependencies. You don't notice this overhead during runtime - VB 6 is fairly fast. You notice it in little code things, like realising that the OLE engine, when faced with: Object1.object2.property Will actually create an instance of "object2" just to execute the property (where you'd think the instance should already be around to use...). Place this inside a loop, and you have an interesting and non-intuitive optimisation problem. Other things like having to .close all JET objects before SETting them to NOTHING. Something you MUSt do to all objects otherwise the garbage collector doesn't tidy up the object's memory properly, internal OLE counters go astray...etc. If you don't .close it first, then the object is cleaned correctly, but all the data elements it may point to indirectly remain. the potential for subtle memory fragmentation is extreme unless you are *very* rigorous with your code. The above is probably why some odd problems happen with VO and ActiveX, as this is a fundamental problem to COM, not VB as such. Basically it comes back to my original point. You CAN do good things with VB, but it takes experience, patience, and a LOT of attention to detail, and your analysis and design. seeya...Pete Peter Fallon www.castlesoftware.com.au Peter, > MS bloke whether this would be fixed (back before VB 5 was released), and he indicated that in MS's view, if you wanted to code professionally, you should be using VC++. > This reminds me about a UG meeting we had last year. We invited a tech guy from MS to show us NT 5, as it was called then. He also showed us VB and VC++ working together. After the meeting I and a few other guys had a talk with this MS guy and asked him about his own oppinion about MS dev tools. His personal oppinion was that you write the user interface with VB because that's easier than with VC++, but you write the business logic in VC++ as VB is just not good enaugh for that. That's the MS guy comments. I cant comment on that as don't use VB or VC++ -- Regards, Lars-Eric http://www.clippersweden.se Lars, > This reminds me about a UG meeting we had last year. We invited a tech guy from MS to show us NT 5, as it was called then. He also showed us VB and VC++ working together. After the meeting I and a few other guys had a talk with this MS guy and asked him about his own oppinion about MS dev tools. His personal oppinion was that you write the user interface with VB because that's easier than with VC++, but you write the business logic in VC++ as VBis just not good enaugh for that. > its also their way of escaping any critisisms of the VB object model (lack of inheritance...etc) - by saying that you should use C++. Evidently MS has tried on a number of occasions to write some of their own (commercial) software in VB, and failed miserably (and then turned to C++). seeya...Pete Peter Fallon www.castlesoftware.com.au Peter, I think you're absolutely right about whether MS eats their own dogfood where VB is concerned. I attended a large MS conference about a year ago in which several large e- commerce case studies were presented. One was an internal MS project and the others were client projects with MS involvement. Anyway, every single one of them ended up using C++ for the business logic even though most of the projects had originally been "prototyped" in VB. One of the presenters (not from MS) was very candid and explained that the VB version just wasn't usable so they had to rewrite. Ginny Ginny, > I think you're absolutely right about whether MS eats their own dogfood where VB is concerned. I attended a large MS conference about a year ago in which several large e- commerce case studies were presented. One was an internal MS project and the others were client projects with MS involvement. Anyway, every single one of them ended up using C++ for the business logic even though most of the projects had originally been "prototyped" in VB. One of the presenters (not from MS) was very candid and explained that the VB version just wasn't usable so they had to rewrite. > compare that with VO, where the whole class engine is VO! Or another example. I attended the first Delphi conference in San Diego back in 95. There, as part of the demo of the upcoming "Delphi 2" (the 32 bit version for Win95), they actually loaded the entire source code for the delphi 1.0 IDE into 2.0 as a project to show its backwards compatibility (It was ALL written in dephi, except for the actual Pascal compiler), and hit Compile - and it did!! (after about 10 minutes, after all it was about 150,000 lines of code...). That was impressive - and showed they weren't afraid to use their own tool!! seeya...Pete Peter Fallon www.castlesoftware.com.au