EBMode works in hook proc set in Add-In

[Elroy]

Not exactly a question, but there is a related question.

I just figured out something potentially useful. It seems that a call to EBMode works as one might hope (1=Runtime, 0=DesignTime) when it's called within a hook procedure within an Add-In. Within my Add-In, I was struggling to figure out whether I was in Runtime or DesignTime, so I tried EBMode, and voila.

It seems that this could be useful for other things as well, such as a small Add-In that could be used for UCs or subclassing to answer this Runtime/DesignTime question. However, testing would be needed to see when EBMode goes true.

Also, and this is the related question ... I don't know of an easy way to easily get data between an Add-In and the code-window VB code I'm writing. It would obviously have to be through some late-bound object so the project would compile. Or, another idea is to communicate through some property of a form in the project, but that feels sloppy.

Any ideas on how to communicate between an Add-In and project code?

Y'all Take Care,
Elroy

[Eduardo-]

Also, and this is the related question ... I don't know of an easy way to easily get data between an Add-In and the code-window VB code I'm writing. It would obviously have to be through some late-bound object so the project would compile. Or, another idea is to communicate through some property of a form in the project, but that feels sloppy.

Any ideas on how to communicate between an Add-In and project code?

What data do you want to get?

You have CodePane and CodeModule objects.

In the CodePane you have, for instance, properties like CodeModule, CountOfVisibleLines and TopLine and methods GetSelection and SetSelection

In the CodeModule you have CodePane, CountOfDeclarationLines, CountOfLines, Lines, ProcBodyLine... and methods InsertLines, DeleteLines, Find and others.

AFAIK there are no events to tell you when the programmer writes something.

[Elroy]

Hi Eduardo,

I'm sorry, I wasn't clear about my question. Let's say I've got some Add-In with a Module1 and a variable in it declared as ...

Public iValue As Long

But now, from my VB6 code (not the Add-In), I'd like to know the value of that iValue variable.

-------------------

Also, regarding ...

AFAIK there are no events to tell you when the programmer writes something.

I could just hook the keyboard for the thread and do that. I'm already doing something similar with the mouse. However, that's not something I need right now. It would be nice to be able to communicate some data between an Add-In and the p-code of a project I'm writing.

Thanks,
Elroy

[qvb6]

You could use something like WM_COPYDATA. I am not sure that there is something built in that lets you talk to Add-ins.

[Eduardo-]

Hi Eduardo,

I'm sorry, I wasn't clear about my question. Let's say I've got some Add-In with a Module1 and a variable in it declared as ...

Public iValue As Long

But now, from my VB6 code (not the Add-In), I'd like to know the value of that iValue variable.

You have two code environments, 1) the add-in and 2) the host program. If it is not from the add-in then it is from the host program, where the variable declaration is.
For the variable to have a value, that host program must be running.

Then, to know its value:

MsgBox iValue

What I'm missing?

[Elroy]

You have two code environments, 1) the add-in and 2) the host program.

Yes, I totally agree, and that's precisely what I'm getting at. It's also interesting that both of those environments are running in the same thread.

For the variable to have a value, that host program must be running.

This is what's not entirely true. There are at least three situations I can think of where this isn't true:

1. Code that's in a UC. This code can execute while in design-mode.
2. Code that's executed in the Immediate Window, that might even call some Public BAS procedures.
3. Subclassed procedure code that's executed after the "Stop" button is clicked. This is often used to clean-up subclassing.

And it's precisely those situations where possibly getting a value out of an Add-In might be useful.

Thanks,
Elroy

[Elroy]

@qvb6: Yes, I'm quite familiar with WM_COPYDATA. However, in addition to the Add-In, that'd take a form in the project dedicated to the Add-In communications. I was hoping for something a bit more simple. But that's certainly an option.

Thanks,
Elroy

[Eduardo-]

This is what's not entirely true. There are at least three situations I can think of where this isn't true:

1. Code that's in a UC. This code can execute while in design-mode.
2. Code that's executed in the Immediate Window, that might even call some Public BAS procedures.
3. Subclassed procedure code that's executed after the "Stop" button is clicked. This is often used to clean-up subclassing.

And it's precisely those situations where possibly getting a value out of an Add-In might be useful.

Thanks,
Elroy

In all cases the code is running.

Anyway, MsgBox iValue was what you were asking for? (I don't think so)

[Eduardo-]

I think what you want is to get the iValue variable value from the add-in.

The host program might be in design mode, but still some parts be running.
As I understand it, it takes times. The moments that those parts are running are shown in the IDE because the caption of the IDE's window says "...[running]"

One way to deal with the issue would be to see them as comunicating two separate programs, something as qvb6 aproach.
There are many ways to communicate two programs as I think that you already know (messages, DDE, files, registry, SetProp/GetProp, Etc.)

Other aproach would be to expose that variable value as a property of an UserControl. That property value could be fetched by the add-in.

What do you think?

[Elroy]

Hi Eduardo,

Yes, those are some good ideas. I'm working on another Add-In at the moment, and I'll start playing with this AddIn-to-Program communication after I finish this other little project. And yeah, you're right about EbMode. I haven't worked out all the details, but it does seem that an AddIn might be able to figure out a basic state of EbMode (running P-Code, designing, running but in break-mode). I'll have to play around with it.

Thanks,
Elroy

[qvb6]

Instead of pulling EBMode, you can get an event from VB when running/stopping a project. These are undocumented events in "Microsoft Visual Basic 6.0 Extensibility". Open Object Browser(F2), right-click anywhere, then enable "Show Hidden Members", then search for "VBBuildEvents". You will find these 3 events:

BeginCompile(VBProject As VBProject)
EnterDesignMode()
EnterRunMode()

I learned about them from a simple Add-in called ImmClear(and the Readme mentions Addin newsgroups). This Add-in clears the Immediate window when you start a project. You can find the Add-in here, along with the source code.

[qvb6]

Also, when clicking on menu items or the toolbar in VB6 IDE, VB sends a message to VB main window with message ID: &H1044. wParam contains the ID of the item clicked. Here are the ones that relates to running projects from an Add-in that I have made:

Public Function VB6IDEWindowProc(ByVal hwnd As Long, ByVal uMsg As Long, _
    ByVal wParam As Long, ByVal lParam As Long) As Long
   
    If hwnd = hWndVB6IDE Then
        Select Case uMsg
            Case &H1044: ' VB6 IDE Toolbar or menu item clicked
                Select Case wParam
                    Case &H31: ' Start <F5>
                    Case &H32: ' Start With Full Compile <Ctrl+F5>
                    Case &HE1: ' Make EXE
                    Case &H30: ' Break <Ctrl+Break>
                    Case &H33: ' End
                    Case &H34: ' Restart <Shift+F5>
                    Case &H35: ' Step Into <F8>
                    Case &H36: ' Step Over <Shift+F8>
                    Case &HAA: ' Step Out <Ctrl+Shift+F8>
                    Case &H37: ' Run To Cursor <Ctrl+F8>
                    Case Else
                        VB6IDEWindowProc = CallWindowProc( _
                            oldVB6IDEWindowProc, hwnd, uMsg, wParam, lParam)
                        Exit Function
                End Select
                'VB6IDEWindowProc = 0 ' Cancel the click
                VB6IDEWindowProc = CallWindowProc(oldVB6IDEWindowProc, _
                    hwnd, uMsg, wParam, lParam)
            Case Else
                VB6IDEWindowProc = CallWindowProc(oldVB6IDEWindowProc, _
                    hwnd, uMsg, wParam, lParam)
        End Select
    Else
        VB6IDEWindowProc = CallWindowProc(oldVB6IDEWindowProc, hwnd, uMsg, _
            wParam, lParam)
    End If
End Function

[Elroy]

Thanks qvb6,

It looks like good stuff. I'll definitely take a look.

Elroy