Script BASIC - VB6 OCX Forms

[AlyssonR]

As to what BASICs support COM/OLE - I have no idea.

Most could, but how many do?

[John]

According to the hard core WinAPI coders, COM/OLE automation is for pussies. I on the other hand value my time and try to give my clients their money's worth by working on their requirements and less on pre-project framework creation.

[AlyssonR]

Hard Core Win/API coders are all known to be crazy 

COM/OLE was originally designed to simplify inter-process communications. Why re-invent the wheel every time you want to do something - and then have to re-re-invent it when a new version of Windows does something different?

If it's a performance-critical application, I can see it, but for most users? A few milliseconds on a screen-load isn't even enough to focus on the next page of data input. We wait longer for a web page to load up.

[John]

The VB6 OCX based Online Dictionary loads instantly. You would never know it's not a compiled application.

[AlyssonR]

Impressive - but when COM/OLE was first developed, machines were much slower.

Remember that a lot of software suffers from bloat - and saving a few clock cycles here and there on a few thousand program threads will take a program from glacial slowness to cold-rice-pudding.

Of course, there's also the Oooooh!  SHINY! NEW! effect that has developers running like lemmings toward the latest and greatest tool (.NET springs to mind here), regardless of whether it is a necessary change or not.

IMHO, COM/OLE was an excellent software device that was dropped for no good and enduring reason - it is more flexible in many ways than the more recent process interfacing API. Certainly, it is better encapsulated for use.

[John]

It's going to be really hard for Microsoft to kill off COM/OLE automation as it is the skeleton of Office. People count on it gluing their world together.

VB6 may be unsupported but VBA is alive and well. COM/OLE automation is used extensively under VBA. (Excel, Word, Outlook, ..., QuickBooks desktop, Crystal Reports, the list goes on and on)

[John]

I'm trying to make the OLD OCX a dual interface but unable to find the checkbox that does so. No luck in the project properties.

The Oxygen Basic DLLC extension module supports a COM direct interface. I'm trying to get the Online Dictionary example to work as a non-iDispatch automation server. I'm using DLLC to prototype the direct interface and once it works, a generic include/library for O2 can be created. (removing SB from the picture)

[AlyssonR]

I suspect that might only be available when you create an ActiveX DLL, as below

[John]

It is an ActiveX DLL. I think I need to import the typelib for v-table (dual interface) access.

From what I've read, v-table (direct)) rather than iDispatch automation is twice as fast.

[John]

At this point due to the lack of interest, I'm going to move on with this for my own needs and stop trying to promote the concept to others. In most programmers minds VB6 is dead and COM/OLE is for those still using it in MS Office automation using VBA.

Thanks AlyssonR for taking the time to provide your feedback!

[AlyssonR]

John,

Once you have this running to your satisfaction, I would be interested in seeing how it works since the process of generating forms from SB, or any other non-VB IDE is, frankly, painful in the extreme.

I'm not ready to start front-end development, but I'm still in the middle of building my back-end software.

Hell, I've even been contemplating writing a widget terminal that would allow the fast generation of forms from a simple set of commands and to then talk to the back-end relatively painlessly.

[John]

Once you have this running to your satisfaction, I would be interested in seeing how it works since the process of generating forms from SB, or any other non-VB IDE is, frankly, painful in the extreme.

The Online Dictionary proof of concept satitified all my requirements and I'm activity moving forward with the concept. I also plan to show direct v-table access as well using the DLLC extension modue.

I'm trying to get the thinBasic community to look at the concept. I believe Eros has COM/OLE automation as a core language feature which would make this a natural for thinBasic.

[John]

Hell, I've even been contemplating writing a widget terminal that would allow the fast generation of forms from a simple set of commands and to then talk to the back-end relatively painlessly.

I hate web UI and graphics work. It's not my strong point. VB6 is my answer to Windows UI based programming. Where I excel is integration and migration tasks.

[AlyssonR]

I detest web UI (in fact any UI) programming with a vengeance, and VB6 has been my go-to for anything that requires interaction up to now - but I want to go cross-platform.

What I want is to be able to put all of the UI into a single program that can then be used by any suitable back-end application without having to use AJAX, HTML forms and such like. Much as a VB program can provide a front-end to other stuff.

The hassle of building user interfaces is a steep learning curve that I feel ill-equipped to deal with - and being able to send what amounts to the VB form building parameters to a front end over what is effectively a serial link (virtual or physical) appeals to me immensely. A serial link, I might add, that maintains stateful information across the link without the Hell-That-Is-Ajax.

That, and I really am too long in the tooth to start wrapping my mind around Java.

[John]

I forgot to mention that VB6 OCX form DLLs using the VBCCR common controls replacement OCX, auto registers the OCX. (no need for regsvr32)