Firefly3, ActiveX controls and other issues

[Michael Stefanik]

First, let me say that I'm impressed with all of the work that you've done with FF3. As you probably know, my company makes Internet components, and having a solution for PB developers who want to (easily) use the ActiveX controls in our SocketTools Visual Edition with PowerBasic and Firefly would be a good thing. I've started doing some testing with our controls, and here's a few things that I've noticed, in no particular order:

Once an ActiveX control has been added to a form, it cannot be selected by clicking on it (dragged, resized, etc.); the only way to select it is using the drop-down list, and even then it's not draggable.

Adding a second ActiveX control can sometimes activate the first, so when you try to position it, you actually end up repositioning the first control. This doesn't happen consistently for me, but I've seen it happen a few times.

To delete an ActiveX control, you first need to select it from the drop-down list in the property browser, and then you have to resize it; otherwise, the delete key is ignored.

ActiveX controls flagged as hidden a still drawn on the form; in other words, the container isn't obeying the OLEMISC_INVISIBLEATRUNTIME flag and always creates a window for the control and tells it to draw to it. Clearing the WS_VISIBLE style has no effect.

Some other general IDE related things that I've run into while testing:

The autocomplete feature can be too aggressive; for example, try typing in this:
Local pFtpClient As IFtpClient

Unless you explicitly hit escape, it always wants to replace IFtpClient with IMAGE_DATA_DIRECTORY. I could see this behavior if the two keywords were even remotely close to one another, but obviously they're not. Earlier versions of Visual Studio did this as well, and it drove me nuts. IMO, as soon as it's clear that what's being typed has no close match to a candidate keyword, it should not attempt to autocomplete for it. In other words, the if the letters "I" "F" "t" and "p" are typed, that should make it clear to the autocomplete code that it should not attempt to complete something that starts with "IMAGE". Autocomplete is handy feature to have enabled, but it should never get in the way of the programmer.

When pasting in a large block of text, the editor pastes it above the insertion point. This is opposite of most editors that I've worked with, but the only reason that it really caught my attention was when I tried to paste the generated COM interface code to an empty module. Give it a try and see what happens. Your code window stays blank, and there's no indication that you've actually pasted in anything except the line count in the status bar on the bottom increases. You have to hit Ctrl+Home (or scroll up) to actually see what was pasted from the clipboard.

When you open the FF3 help, it's created as a topmost window. While some people may like this, I find it to be really distracting. I looked around for an option to disable this behavior, and couldn't find it.

When you have the FF3 help open and then press F1 with a PB keyword highlighted, the PB help opens but is completely non-responsive; making the IDE active sometimes fixes the problem, but sometimes the IDE just crashes.

Speaking of help files, is it possible to integrate third-party help into the IDE, similarly to how the PB editor supports third-party help? It would be a nice feature to have.

[Rolf Brandt]

I agree to what you said about the FF3 help. It schould not be a topmost window. Usually I work with two monitors, so I just shift it to the right screen and it does not bug me. But if you work with one monitor or a notebook it can be annoying when you have to either close the help window or push it around all the time.

Rolf

[Michael Stefanik]

With regards to dragging an ActiveX control when designing a form, I found there's a very narrow area near the grab handles where you can actually click and drag; but if you actually try to click and drag anywhere in the client area of the control, it doesn't work.

As an example, add the Microsoft Calendar control to a form, then click on the form background (so the calendar control is no longer selected). Next, put the mouse pointer over the "Nov 2009" on the control, and try to click and drag the control.

The first thing you'll notice is that you can't select the control. If you manually select it using the drop-down list in the property browser, and then go back to the "Nov 2009" area of the control, you'll see that it's still not draggable.

Contrast this to Visual Basic's behavior, where left-clicking and dragging anywhere in the client area of a control allows it to be moved.

[Paul Squires]

Hi Mike,

Thanks for the suggestions and observations. The narrow margin around the edge of an ActiveX control is actually the container window that is the parent of the control. It is the same behaviour as FF2. I think that I did not allow the actual ActiveX control to be clicked on and dragged because to do so meant that I would have to subclass the control in order to catch the mouseclicks, etc... IIRC, back in FF2 when I tried doing this that some ActiveX controls did not like the subclassing one bit and caused random GPFs. I could try this again in FF3... maybe I was doing it wrong in FF2 (that was about 4 years ago).

I will log all of the other comments and work on them for an upcoming update.

Thanks!

[Michael Stefanik]

When you create an instance of the control in your container, are you letting the control know that it's in design mode? That's determined by one of the ambient properties, DISPID_AMBIENT_USERMODE, and if the control thinks it's in user mode (i.e.: that it's executing in the context of a running program, not simply being created by a visual designer) it may cause some of the problems that you experienced. I know in our controls we have a lot of checks to see whether we're in design mode or user mode.

[Paul Squires]

I am not doing any checking when the control is added to the container. I am following the lead as outlined by Jose Roca for creating ActiveX controls via his new OLE Container code.

I'll certainly look at the ActiveX issues to see if we can come to a solution.

[Paul Squires]

Oh, I forgot to mention, I fixed that "large block of text" pasting issue. It was easier to fix than I thought. I should have changed that behaviour months ago. 

[Paul Squires]

The autocomplete feature can be too aggressive; for example, try typing in this:
Local pFtpClient As IFtpClient

Unless you explicitly hit escape, it always wants to replace IFtpClient with IMAGE_DATA_DIRECTORY. I could see this behavior if the two keywords were even remotely close to one another, but obviously they're not. Earlier versions of Visual Studio did this as well, and it drove me nuts. IMO, as soon as it's clear that what's being typed has no close match to a candidate keyword, it should not attempt to autocomplete for it. In other words, the if the letters "I" "F" "t" and "p" are typed, that should make it clear to the autocomplete code that it should not attempt to complete something that starts with "IMAGE". Autocomplete is handy feature to have enabled, but it should never get in the way of the programmer.

I spent some time this morning working on the CodeComplete stuff. It is now working *much* better. It is no longer aggressive as outlined in Mike's post. It also adds the ENTER or SPACE to the text if either of those keys are pressed in order to trigger the CodeComplete. The result is that it works pretty identical to VB6.

Fix will be in v3.03.

[Paul Squires]

When you open the FF3 help, it's created as a topmost window. While some people may like this, I find it to be really distracting. I looked around for an option to disable this behavior, and couldn't find it.

When you have the FF3 help open and then press F1 with a PB keyword highlighted, the PB help opens but is completely non-responsive; making the IDE active sometimes fixes the problem, but sometimes the IDE just crashes.

Fixed.

Fix will be in v3.03

[Michael Stefanik]

That was fast!

[Paul Squires]

ActiveX controls flagged as hidden a still drawn on the form; in other words, the container isn't obeying the OLEMISC_INVISIBLEATRUNTIME flag and always creates a window for the control and tells it to draw to it. Clearing the WS_VISIBLE style has no effect.

I am using Jose Roca's OLECON.INC container code to host the ActiveX controls. I read down through the code and it appears that it leans towards visual controls only. There is no mention of the OLEMISC_INVISIBLEATRUNTIME flag anywhere in the code being tested.

So, I am not sure how to go about addressing this concern. Maybe you will have to create these types of non-visual controls directly in code rather than during design time?

[Michael Stefanik]

The workaround for the problem is to use ShowWindow to hide the control window in the WM_CREATE handler for the form it was dropped on. I think it would be something worth looking at long-term, but it's not critical and it's easy to address

[José Roca]

I am using Jose Roca's OLECON.INC container code to host the ActiveX controls. I read down through the code and it appears that it leans towards visual controls only. There is no mention of the OLEMISC_INVISIBLEATRUNTIME flag anywhere in the code being tested.

Both ATL.DLL and my OLE container are designed as lightweight custom controls to host visual OCXs with some limitations (e.g. controls used to host other controls aren't supported). Flags like OLEMISC_INVISIBLEATRUNTIME have not meaning to them because, at runtime, the only possible answer is False (if it is not a visual OCX then you don't need a container to use them). The needs for integration in a visual designer are much greater, but I'm afraid that I don't have the time, resources and knowledge to write a container as complex as the one used by VB.

Besides, because of the non vaporware policy, we don't know if PB will add an OLE container to a future version of the compiler or not; and if it adds it, if it will be usable with SDK or will be only a DDT thingy such the graphic control. If it adds one and can be used with SDK, then all we are doing now will go directly to the trash binder, so it's not worth the effort. FireFly is above all a SDK visual designer.