VBA to monitor/alert when/if a ActiveCodePane.Window = "General" has focus

[EagleOne]

2003, 2007

The following will work when executed.

If Application.VBE.VBProjects.VBE.ActiveCodePane.Window.Caption = "General" Then
MsgBox Application.VBE.VBProjects.VBE.ActiveCodePane.Window.Caption & " is Open"
End if

How can the same logic be coded into a "Monitor" event? Similar to "On error goto" where if a error
occurs while executing a sub proceedure.

In short, when a user opens a specific VBProject code window (Caption: = "General") Then
a MsgBox displays a message like above.

TIA EagleOne

 

[Jim Cone]

If you password protect the project in the VBE then users can't open the project.
--
Jim Cone
Portland, Oregon USA



<[email protected]>
wrote in message
2003, 2007
The following will work when executed.

If Application.VBE.VBProjects.VBE.ActiveCodePane.Window.Caption = "General" Then
MsgBox Application.VBE.VBProjects.VBE.ActiveCodePane.Window.Caption & " is Open"
End if
How can the same logic be coded into a "Monitor" event? Similar to "On error goto" where if a error
occurs while executing a sub proceedure.

In short, when a user opens a specific VBProject code window (Caption: = "General") Then
a MsgBox displays a message like above.
TIA EagleOne

 

[Peter T]

The VBIDE windows do not expose any events that you can trap in VBA, at
least not directly. You could sub-class it's windows and there is a nice
helper C dll that avoids most of the problems normally associated with
hooking into Windows events, ie OS events (overkill I would think).

Alternatively and much simpler, why not run a macro with a regular timer,
even VBA's own Ontime method if every one or more seconds is frequent is
enough (be sure to run schedule:=false to stop it when done, eg wb close
event).

.ActiveCodePane.Window.Caption = "General"
Is that really enough to determine if your module is being played with. It
might include (code) or be prefixed with the wb name. What about -
.ActiveCodePane.CodeModule.Name

Regards,
Peter T

 

[EagleOne]

Jim is heard from!

Jim you and I know that cracking passwords is simple and done all the time. I need something more
clever.

Thanks

 

[EagleOne]

Peter,

I did think about wrapping a routine in a timer loop which I believe you are suggesting.
My initial reaction was "that is not efficient" or maybe not the smartest approach.

I just finished a week of being a 1st-timer creating an Excel Add in and COM DLL.
My info source was Chip Pearson site.

At this point, I do not have the time to migrate my VBA to VB.NET. Thus, I am looking for sweet but
smart alternatives.

Thanks for your time and knowledge. I'll look up Ontime.

 

[Dave Peterson]

If you don't trust protecting the project, then I hope you wouldn't trust
anything written in VBA--since macros can be disabled.

Maybe it's time to learn about compiled languages and COM addins.

I'd start here:
http://www.cpearson.com/excel/CreatingCOMAddIn.aspx

 

[Dave Peterson]

Ps. That site is Chip Pearson's.

If you don't trust protecting the project, then I hope you wouldn't trust
anything written in VBA--since macros can be disabled.

Maybe it's time to learn about compiled languages and COM addins.

I'd start here:
http://www.cpearson.com/excel/CreatingCOMAddIn.aspx

 

[Peter T]

I did think about wrapping a routine in a timer loop which I believe you

are suggesting.
My initial reaction was "that is not efficient" or maybe not the smartest
approach.

Worse than merely inefficient, it would prevent anything else from working
both in Excel and VBA.

Let's say, with a timer perhaps, you end up with a viable means of
determining if the active codemodule is yours - then what?

Regards,
Peter T

 

[EagleOne]

Another XL brainiac is heard.

Dave, I just finished a week of COM addin study based on Chip's excellent information.

Based upon my reading, I must migrate my VBA to VB.NET to get my procedures and functions to compile
(.dll) in VB.NET.

So as Plan B, I am planning a COM Addin with a Ontime routine to check if someone has successfully
defeated the VB password. Maybe I am just fooling myself. My guess is that hackers can reverse
engineer dll's.

Are you aware of any short/sweet written recap(s) and/or s/e migration packages which will migrate
VBA to VB.NET?

Thanks for your time and knowledge.

EagleOne

 

[Dave Peterson]

I don't know of any migration packages like that, but I don't use .NET.

 

[EagleOne]

I figured that. Which do you prefer C# or C++?

I don't know of any migration packages like that, but I don't use .NET.

 

[Dave Peterson]

Both are ok with me. But I don't use them either <vbg>.

 

[Peter T]

I don't know much about .NET but pretty sure it doesn't have an OnTime
method like VBA, though there will be alternatives of course.

I'm missing something, why would you be concerned about someone breaking
your VBA password if no longer have any VBA code and have ported everything
to .NET.

As for decompiling - I've read that .Net-visualbasic can be hacked but you'd
need to be very familiar with .NET to be able to do that and then for it to
be worthwhile. Curiosity - why do you think someone might go to the lengths
of doing that. (FWIW a VB6 dll is virtually impossible to decompile.)

Regards,
Peter T

 

[EagleOne]

Peter,

I have not yet ported my VBA to .net. Last week, I spent a good deal of time learning how to create
a DLL in VB.NET. Purpose to secure my VBA code. Then I found out that I could not just copy my VBA
code into a VB.NET Class section then compile. That can not be done.

So I'm thinking of Plan B which is leaving it in VBA but making it difficult to reach.

What I do want to do is to migrate the Ontime code to a VB.NET DLL. I realize that I may have to
use VB.NET equivalent if available. Then I'll load/execute the DLL which, hopefully, will work in
VBE.

Thanks for you help - which was significant.

EagleOne

 

[Patrick Molloy]

why don't you just create the com object in VB6? Isn't that what Dave P is
hinting at?

Peter,

I have not yet ported my VBA to .net. Last week, I spent a good deal of
time learning how to create
a DLL in VB.NET. Purpose to secure my VBA code. Then I found out that I
could not just copy my VBA
code into a VB.NET Class section then compile. That can not be done.

So I'm thinking of Plan B which is leaving it in VBA but making it
difficult to reach.

What I do want to do is to migrate the Ontime code to a VB.NET DLL. I
realize that I may have to
use VB.NET equivalent if available. Then I'll load/execute the DLL which,
hopefully, will work in
VBE.

Thanks for you help - which was significant.

EagleOne

 

[EagleOne]

Pat, good point!, but I do not have access to VB6. I would buy it if it were available at a
reasonable price realizing that it is an MS officially obsolete program. Therefore I am stuck with
VB.NET.

"EagleOne" (e-mail address removed)