I am going to write an HMI application and use an ActiveX control from either InGear or Automated Solutions to interface with an Allen-Bradley SLC505. I don't know which is the better Development Tool... C++ Builder 5.0 or Visual Basic 6.0. Has anybody had any positive/negative experience with using either Builder or VB with those ActiveX controls. I would prefer to use Builder, but not if I'm going to have problems.

Thanks,
Victor

 

I have used the Automated Solutions ActiveX component in Visual Basic 6.0 and have had good results. The only issue I currently have is migrating an app from 98 to NT, but when I asked A.S. for help, they set up a test environment and ran my source for a couple days and proved out their component, so it probably just needs a recompile...

Anyway, I recommend Automated Solutions to anyone who asks.

--Joe Jansen

 

I've rarely had problems with any ActiveX component under C++ builder, and much prefer it to Visual Basic. Try a mockup in Builder to test the component.

IMHO, stick with the language you prefer - and use the tools that work with it (and if a particular component doesn't work, nag the component vendor to make their product comply with the standards!)

------------------------------------------
Robert Antonishen, P.Eng.
Sr. Eng - IMO Integration Project
Commercial Systems - Commercial Operations
Ontario Power Generation
phone 416-592-1510 fax 416-592-2889
[email protected]
------------------------------------------

 

Of course C++ builder and Visual Basic are not 'equivalent' products.

My own experience of Visual C++, Visual Basic, and C++ Builder lead me to think that C++ builder is somewhere between Visual C++ and visual basic. Borlands underlying compiler is full strength, and I have had no problems using code taken from other sources, including a fortran routine that I ran through GNU's f2c converter. But the C++ builder GUI front end and dialog editor etc is much easier to use than Visual C, probably because it is also simpler.

VC is probably great if you have, say, 30 engineers working on a major project simultaneously with graphics people and marketing defining the exact look and feel. But more humble work with a few people working on a specialist app or 'bespoke' software do not require the sophistication. Microsoft themseleves acknowledge that developers need a year until they get up to full speed with visual C. Their solution is that VB should be used for lesser apps. But of course VB is quite high level, and results depend on the underlying objects that are being invoked. Things go great when you are in the realm of office automation, which is the market VB targets, but in IA you cannot always rely on ready made objects that are just right for your needs.

Also, VB's insistance on not allowing pointers means things get very messy very quickly in multi-dimensional problems. Likewise tying code to events cannot be done in a very flexible way.

As for Active X objects, you are just as likely to have problems with VB as you are with C++ builder. The difference is that if you have
problems with C++ builder everybody blames this suggesting that you port the whole lot to MS tools, whilst if you have problems with VB they mumble "version problems....DLL's.....we are looking into it....".

If the problem is small and simple (and will not need to be expanded in the future) VB is probably your best bet. Also, if the software is for your own internal use, VB may wash anyway, as what happens with VB is that you get 90% done very quickly, but stumble on a few little pieces. If this is in house you can perhaps work round problems taking liberty with the spec. If however you have a customer who wants "this", you can soon
have embarresing delays and egg on your face.

If you do not go the VB route, C++ builder is likely to be prefferable over VC. Even with risk of eventual Active X hiccups, it is less trouble
to sort them out than go to VC.