When testing our ActiveX controls, I began thinking about how FF3 could make the process more seamless for the developer. Here's a suggestion, in steps:
Add a project option to "Add Reference" (i.e.: Project | Add Reference from the menu, etc.) that's similar ini functionality to Visual Studio. In other words, it opens a dialog that displays a list of available ActiveX controls. This could be similar to what's shown by the TypeLib browser, but rather than the module name and path, just showing the control's name and version information (which I think would be more useful). Adding a reference to a control would automatically create modules from the code generated by the TypeLib browser, and would add those modules to the project; no more cutting and pasting.
Once you've added a reference to a control in your project, you can then select that control from a drop-down list when you add an "OCX/ActiveX" control to the form. In other words, rather than pasting in a ProgID for the control, it's a listbox that displays the controls that have been added as references to the project. So, adding an ActiveX control would simply involve a) adding a reference to the control, b) selecting the control from a list. No need to cut-and-paste ProgIDs, create new modules and paste in interface code, etc.
Also, have you considered actually redistributing Jose's include files with Firefly, if he would be open to that idea? Providing an alternative set of includes as part of the base installation, perhaps in a Documents\Firefly Visual Designer\Include folder? And allow the new project settings to use those as a default, if the developer wants. I know that he updates those headers semi-regularly, but I still think having them installed would be a nice touch.
I agree that ActiveX integration could be better. Back in my old Visual Basic days, using ActiveX controls was so easy - exactly like you have described it.
In FF3, I had to make some design concessions because all the ActiveX stuff depends on other parties (Jose or PB itself).
It would be cool if I could all call Jose's program and automatically get the information needed to make the process a little smoother. Automatically creating the necessary modules is easy bit getting the information to put in them is a little more involved. Maybe at some point down the road we can all get together to revisit this topic to see if we can come to a mutual solution to make the process better for everyone.
Firefly already makes the process pretty simple, I was just thinking of how it could even be more plug-and-play. With less manual intervention and "glue code" required, the fewer mistakes that people can make in the process.
What I may do is simply pre-generate a group of include files for SocketTools, clean them up a bit and make them available for any developers who prefer the higher level interface of the ActiveX controls over the lower-level API. That way they could just drop them into their project and be ready to go. When we've gotten questions about using our controls with PowerBasic, I've recommended Firefly because it offers a very nice development environment and the smoothest transition for Visual Basic programmers who are used to a design-centric, even-driven approach to coding rather than the traditional SDK approach.
I can envision this on the download page in the future ... 8o)
«I've recommended Firefly because it offers a very nice development environment and the smoothest transition for Visual Basic programmers who are used to a design-centric, even-driven approach to coding rather than the traditional SDK approach».
Mike Stefanik
Catalyst Development Corporation
I'd hope Paul fixes my spelling ("event-driven"), but aside from that, he's more than welcome to quote me.
QuoteI've recommended Firefly because it offers a very nice development environment and the smoothest transition for Visual Basic programmers who are used to a design-centric, even-driven approach to coding rather than the traditional SDK approach.
I don't totally disagree, but I still maintain that it would be nice if a comment was added to the FF generated source code that a specific FF event for a form or control is the equivalent VB event. I've noticed that a large percentage of the questions from former VB users here and on the PB forums are about Windows Messages, events, and how VB command/functionality relates to PB. A simple comment in the code would serve to immediately educate new users to the PB way of doing things and reassure the "newbies" they are proceeding in the right direction with their coding efforts. As far as I know no PB development system offers this functionality and if FF offered this facility I think it would boost sales considerably.
Of course I would want the ability to turns these "comments" on and off.
JR
Quote
I agree that ActiveX integration could be better.
IMO,
Now that VB is dead, I don't see a bright future for ActiveX controls. Just providing support to allow the use of the existing ones during the transition period should be enough.
The new Windows 7 Ribbon control shows the way: it uses low-level interfaces instead of Automation. This means faster and safer execution, lack of bloat and better integration with SDK windows since there is not need for an OLE container to host them. They are the old good custom controls but using methods and properties instead of sending messages, and receiving COM events instead of notification messages.
Since PB supports direct interface calls and low-level event classes, it is very well suited to use these new type of controls.
VB ain't dead Jose â€" is it ...? 8o)
To me, FF is the replacement for VB. I just cannot seem to enjoy the thought of .NET applications and their requirement for installing multiple frameworks ranging from ~20MB and tenfold that. I by the way resent the logic in the ribbons and have jumped over quite a few applications just because it gets to me.
Quote from: Jose Roca on November 10, 2009, 01:14:42 PM
Now that VB is dead, I don't see a bright future for ActiveX controls. Just providing support to allow the use of the existing ones during the transition period should be enough.
I wouldn't count ActiveX/COM out, the rumors of its impending demise have been around since .NET 1.0 was released. As it turns out, that COM is still a large, core part of how Windows works, and while Microsoft has been making incremental steps here and there to streamline their technology, it's not going anywhere soon.
And while the VB6 IDE is no longer being supported by Microsoft, it's not really correct to say that "VB is dead". In fact, Microsoft themselves would disagree with you. Check out the Visual Basic 6.0 Resource Center (http://msdn.microsoft.com/en-us/vbrun/default.aspx). Bottom line, Microsoft has ensured the long-term survival of VB applications by tying the VB runtime to the lifecycle of Vista and Windows 7. They will continue to support classic VB applications on their platforms until at least 2020.
Another thing to keep in mind is that it's not just VB that uses ActiveX. A bunch of other languages, from various scripting languages to FoxPro, Delphi, etc. also have intrinsic support for ActiveX controls.
While ActiveX is admittedly long in the tooth, it's far away from being dead technology. And make no mistake about it, although Microsoft has been flirting with expanding core APIs and reverting back to native coding circ 1995 in some cases, .NET is without question still the big dog on the block. The vast majority of their developer resources are centered around .NET. Technology, that by the way, can be leveraged by native programs using (drumroll ...) COM.
Quote from: Haakon Birkeland on November 10, 2009, 01:34:30 PM
VB ain't dead Jose â€" is it ...? 8o)
Yes, it is. M$ no longer cares to make his new controls and COM servers usable with VB. This means death by obsolescence.
Quote
I by the way resent the logic in the ribbons and have jumped over quite a few applications just because it gets to me.
I have mentioned the Ribbon control only because it is the first one that uses the new way of building controls. It doesn't matter if it is a ribbon or a button. My purpose was to illustrate what I think is the shape of things to come.
I see. Anywhere/thing on-line that comes to mind where "we" could find something to read about the matter â€" without getting in it too deep?!
Mike,
I don't mean that COM is dead. M$ is still writing all his new technologies using COM and then writing wrapper assemblies to make them available to .NET programmers. Even the .NET runtime is a COM server!
But the new COM servers are being written using low-level interfaces. This means that they aren't usable by Automation languages, unless somebody writes a wrapper automation server or ActiveX for them.
The good news for us is that they are usable directly with PB, without the need for wrappers, OLE containers and the like.
Quote from: José Roca on November 10, 2009, 02:04:36 PM
But the new COM servers are being written using low-level interfaces. This means that they aren't usable by Automation languages, unless somebody writes a wrapper automation server or ActiveX for them.
I don't know that you can really extrapolate that because some interfaces like the new Scenic Ribbon API doesn't use an automation-compatible interface that means everything is going that route. It's clear that they're not going to be building full-on ActiveX controls for it, but I don't know that is the final arbiter of what technology is "dead" or not.
Years ago, Microsoft tried to declare that classic VB was "deprecated" (or "dead") and a legion of programmers stood up and said "oh no, no it's not" and guess what? Microsoft actually relented and has sinced acknowledged that they need to continue to support the ton of software out there still being maintained and written in VB6. What I'm getting at here is that Microsoft is a lot less autocratic that it used to be, and they alone don't decide if a particular technology is dead or not -- the developers and users have a hand in it, and they've learned the hard way that making unilateral decisions to forcibly kill off a technology is not something that's generally well-received in the developer community.
Edit: As for the ribbon API in particular, I guarantee you there will be multiple ActiveX controls that implement the API so that VB6 developers can take advantage of it from classic VB; particularly since Microsoft has said they're going to backport it to Vista as well. So while it may not be an official Microsoft control, I seriously doubt that VB programmers will be left out in the cold. Bottom line, I don't see VB6 or ActiveX controls going anywhere in the forseeable future.
Well, at least now there will be them who will need to write the wrappers, not us.