2003, 2007

The following will work when executed.

If Application.VBE.VBProjects.VBE.ActiveCodePane.Wind ow.Caption = "General" Then
MsgBox Application.VBE.VBProjects.VBE.ActiveCodePane.Wind ow.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

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




wrote in message
2003, 2007
The following will work when executed.

If Application.VBE.VBProjects.VBE.ActiveCodePane.Wind ow.Caption = "General" Then
MsgBox Application.VBE.VBProjects.VBE.ActiveCodePane.Wind ow.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

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


wrote in message
...
2003, 2007

The following will work when executed.

If Application.VBE.VBProjects.VBE.ActiveCodePane.Wind ow.Caption =
"General" Then
MsgBox Application.VBE.VBProjects.VBE.ActiveCodePane.Wind ow.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 is heard from!

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

Thanks

"Jim Cone" wrote:


If you password protect the project in the VBE then users can't open the project.

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.

"Peter T" <peter_t@discussions wrote:

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


wrote in message
.. .
2003, 2007

The following will work when executed.

If Application.VBE.VBProjects.VBE.ActiveCodePane.Wind ow.Caption =
"General" Then
MsgBox Application.VBE.VBProjects.VBE.ActiveCodePane.Wind ow.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

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 he
http://www.cpearson.com/excel/CreatingCOMAddIn.aspx

wrote:

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

"Jim Cone" wrote:


If you password protect the project in the VBE then users can't open the project.

--

Dave Peterson

Ps. That site is Chip Pearson's.

Dave Peterson wrote:

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 he
http://www.cpearson.com/excel/CreatingCOMAddIn.aspx

wrote:

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

"Jim Cone" wrote:


If you password protect the project in the VBE then users can't open the project.

--

Dave Peterson

--

Dave Peterson

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


wrote in message
...
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.

"Peter T" <peter_t@discussions wrote:

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


wrote in message
. ..
2003, 2007

The following will work when executed.

If Application.VBE.VBProjects.VBE.ActiveCodePane.Wind ow.Caption =
"General" Then
MsgBox Application.VBE.VBProjects.VBE.ActiveCodePane.Wind ow.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

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 wrote:

Ps. That site is Chip Pearson's.

Dave Peterson wrote:

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 he
http://www.cpearson.com/excel/CreatingCOMAddIn.aspx

wrote:

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

"Jim Cone" wrote:


If you password protect the project in the VBE then users can't open the project.

--

Dave Peterson

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

wrote:

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 wrote:

Ps. That site is Chip Pearson's.

Dave Peterson wrote:

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 he
http://www.cpearson.com/excel/CreatingCOMAddIn.aspx

wrote:

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

"Jim Cone" wrote:


If you password protect the project in the VBE then users can't open the project.

--

Dave Peterson

--

Dave Peterson

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


Dave Peterson wrote:

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

wrote:

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 wrote:

Ps. That site is Chip Pearson's.

Dave Peterson wrote:

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 he
http://www.cpearson.com/excel/CreatingCOMAddIn.aspx

wrote:

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

"Jim Cone" wrote:


If you password protect the project in the VBE then users can't open the project.

--

Dave Peterson

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

wrote:

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

Dave Peterson wrote:

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

wrote:

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 wrote:

Ps. That site is Chip Pearson's.

Dave Peterson wrote:

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 he
http://www.cpearson.com/excel/CreatingCOMAddIn.aspx

wrote:

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

"Jim Cone" wrote:


If you password protect the project in the VBE then users can't open the project.

--

Dave Peterson

--

Dave Peterson

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



wrote in message
...
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 wrote:

Ps. That site is Chip Pearson's.

Dave Peterson wrote:

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 he
http://www.cpearson.com/excel/CreatingCOMAddIn.aspx

wrote:

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

"Jim Cone" wrote:


If you password protect the project in the VBE then users can't open
the project.

--

Dave Peterson

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



wrote in message
...
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 wrote:

Ps. That site is Chip Pearson's.

Dave Peterson wrote:

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 he
http://www.cpearson.com/excel/CreatingCOMAddIn.aspx

wrote:

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

"Jim Cone" wrote:


If you password protect the project in the VBE then users can't open
the project.

--

Dave Peterson

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


"Peter T" <peter_t@discussions wrote:

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



wrote in message
.. .
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 wrote:

Ps. That site is Chip Pearson's.

Dave Peterson wrote:

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 he
http://www.cpearson.com/excel/CreatingCOMAddIn.aspx

wrote:

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

"Jim Cone" wrote:


If you password protect the project in the VBE then users can't open
the project.

--

Dave Peterson

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

wrote in message
...
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


"Peter T" <peter_t@discussions wrote:

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



wrote in message
. ..
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 wrote:

Ps. That site is Chip Pearson's.

Dave Peterson wrote:

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 he
http://www.cpearson.com/excel/CreatingCOMAddIn.aspx

wrote:

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

"Jim Cone" wrote:


If you password protect the project in the VBE then users can't
open
the project.

--

Dave Peterson

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"

"Patrick Molloy" wrote:

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

wrote in message
.. .
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


"Peter T" <peter_t@discussions wrote:

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



wrote in message
...
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 wrote:

Ps. That site is Chip Pearson's.

Dave Peterson wrote:

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 he
http://www.cpearson.com/excel/CreatingCOMAddIn.aspx

wrote:

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

"Jim Cone" wrote:


If you password protect the project in the VBE then users can't
open
the project.

--

Dave Peterson