[GetMacroRegId] in Immediate window

[bigHatNoCattle]

Help please,

I just switched from Office 2000 to 2003. Here's an example of what
I'm getting in the Immediate window.

[GetMacroRegId] 'fnWeekNum' <
[GetMacroRegId] 'fnWeekNum' -> '216727643' >


How do I get rid of this junk?

thanks

Duane

 

[John Coleman]

I noticed something similar when I switched to Excel 2003. I had a
momentary fear that a virus had somehow infiltrated Excel, but I was
able to track it down to an Excel 4 macro that the Solver add-in was
using to run some initialization/registration code. I don't know what
changed between Excel 2000 and 2003 for this change in behavior in old
add-ins. I just highlight and delete - annoying maybe but over in a
second.

 

[Dave Peterson]

IIRC, this junk is left over from a "debug.print" in the analysis toolpak.

You'd have to know the password to clean it up.

(or just ignore it???)

Help please,

I just switched from Office 2000 to 2003. Here's an example of what
I'm getting in the Immediate window.

[GetMacroRegId] 'fnWeekNum' <
[GetMacroRegId] 'fnWeekNum' -> '216727643' >

How do I get rid of this junk?

thanks

Duane

 

[bigHatNoCattle]

IIRC, this junk is left over from a "debug.print" in the analysis toolpak.

You'd have to know the password to clean it up.

(or just ignore it???)

Help please,

I just switched from Office 2000 to 2003. Here's an example of what
I'm getting in the Immediate window.

[GetMacroRegId] 'fnWeekNum' <
[GetMacroRegId] 'fnWeekNum' -> '216727643' >

How do I get rid of this junk?

Duane

How do I get the password and specifically what steps do I take to
delete the debug code?

Duane

 

[bigHatNoCattle]

IIRC, this junk is left over from a "debug.print" in the analysis toolpak.

You'd have to know the password to clean it up.

(or just ignore it???)

bigHatNoCattle wrote:

Help please,
I just switched from Office 2000 to 2003. Here's an example of what
I'm getting in the Immediate window.
[GetMacroRegId] 'fnWeekNum' <
[GetMacroRegId] 'fnWeekNum' -> '216727643' >
How do I get rid of this junk?
thanks
Duane

--

Dave Peterson

How do I get the password and specifically what steps do I take to
delete the debug code?

Duane- Hide quoted text -

- Show quoted text -

This debug.print code in the anylsis toolpack causes debugging my
Visual Basic code extremly difficult since it clutters up the
Immediate window. Also it slows down my code. Does Microsoft have a
patch?

Duane

 

[Dave Peterson]

The password for protected addins (either solver or the analysis toolpak) is
there because the owner didn't want its intellectual property shared.

I think it's a good idea to respect that.

IIRC, this junk is left over from a "debug.print" in the analysis toolpak.

You'd have to know the password to clean it up.

(or just ignore it???)

Help please,

I just switched from Office 2000 to 2003. Here's an example of what
I'm getting in the Immediate window.

[GetMacroRegId] 'fnWeekNum' <
[GetMacroRegId] 'fnWeekNum' -> '216727643' >

How do I get rid of this junk?

Duane

How do I get the password and specifically what steps do I take to
delete the debug code?

Duane

 

[bigHatNoCattle]

The password for protected addins (either solver or the analysis toolpak) is
there because the owner didn't want its intellectual property shared.

I think it's a good idea to respect that.

IIRC, this junk is left over from a "debug.print" in the analysis toolpak.
You'd have to know the password to clean it up.
(or just ignore it???)
bigHatNoCattle wrote:
Help please,
I just switched from Office 2000 to 2003. Here's an example of what
I'm getting in the Immediate window.
[GetMacroRegId] 'fnWeekNum' <
[GetMacroRegId] 'fnWeekNum' -> '216727643' >
How do I get rid of this junk?
thanks
Duane

How do I get the password and specifically what steps do I take to
delete the debug code?

Duane

--

Dave Peterson- Hide quoted text -

- Show quoted text -

As someone who make his living writing software I agree with you. Ok
so I can't get the password.... so back to my original question... how
do I get rid the debug.print code ( [GetMacroRegId] ) that writes to
the Immediate window?

thanks

Duane

 

[Chip Pearson]

The password for protected addins (either solver or the analysis toolpak)

is
there because the owner didn't want its intellectual property shared.

Actually, there is nothing to see in these add-ins. All they do is call
registered functions in a DLL. If you were to open up the XLA add-ins, all
you'd see is calls to the DLLs that do the real work, and of course the
Debug.Print statements that started this discussion. You wouldn't see any
code that does the calculations.


--
Cordially,
Chip Pearson
Microsoft MVP - Excel
Pearson Software Consulting, LLC
www.cpearson.com
(email address is on the web site)

The password for protected addins (either solver or the analysis toolpak)
is
there because the owner didn't want its intellectual property shared.

I think it's a good idea to respect that.

IIRC, this junk is left over from a "debug.print" in the analysis
toolpak.

You'd have to know the password to clean it up.

(or just ignore it???)

bigHatNoCattle wrote:

Help please,

I just switched from Office 2000 to 2003. Here's an example of what
I'm getting in the Immediate window.

[GetMacroRegId] 'fnWeekNum' <
[GetMacroRegId] 'fnWeekNum' -> '216727643' >

How do I get rid of this junk?

thanks

Duane

How do I get the password and specifically what steps do I take to
delete the debug code?

Duane

 

[Dave Peterson]

I didn't say it was valuable intellectual property <vbg>. I just said it
belonged to the people/company that wrote the addin.

The password for protected addins (either solver or the analysis toolpak)
is
there because the owner didn't want its intellectual property shared.

Actually, there is nothing to see in these add-ins. All they do is call
registered functions in a DLL. If you were to open up the XLA add-ins, all
you'd see is calls to the DLLs that do the real work, and of course the
Debug.Print statements that started this discussion. You wouldn't see any
code that does the calculations.

--
Cordially,
Chip Pearson
Microsoft MVP - Excel
Pearson Software Consulting, LLC
www.cpearson.com
(email address is on the web site)

The password for protected addins (either solver or the analysis toolpak)
is
there because the owner didn't want its intellectual property shared.

I think it's a good idea to respect that.

IIRC, this junk is left over from a "debug.print" in the analysis
toolpak.

You'd have to know the password to clean it up.

(or just ignore it???)

bigHatNoCattle wrote:

Help please,

I just switched from Office 2000 to 2003. Here's an example of what
I'm getting in the Immediate window.

[GetMacroRegId] 'fnWeekNum' <
[GetMacroRegId] 'fnWeekNum' -> '216727643' >

How do I get rid of this junk?

thanks

Duane

--

Dave Peterson

How do I get the password and specifically what steps do I take to
delete the debug code?

Duane

 

[Dave Peterson]

You'd need the password--or a way around the password.

Maybe someone will share it. I won't.

The password for protected addins (either solver or the analysis toolpak) is
there because the owner didn't want its intellectual property shared.

I think it's a good idea to respect that.

IIRC, this junk is left over from a "debug.print" in the analysis toolpak.

You'd have to know the password to clean it up.

(or just ignore it???)

bigHatNoCattle wrote:

Help please,

I just switched from Office 2000 to 2003. Here's an example of what
I'm getting in the Immediate window.

[GetMacroRegId] 'fnWeekNum' <
[GetMacroRegId] 'fnWeekNum' -> '216727643' >

How do I get rid of this junk?



Dave Peterson

How do I get the password and specifically what steps do I take to
delete the debug code?

Duane

--

Dave Peterson- Hide quoted text -

- Show quoted text -

As someone who make his living writing software I agree with you. Ok
so I can't get the password.... so back to my original question... how
do I get rid the debug.print code ( [GetMacroRegId] ) that writes to
the Immediate window?

thanks

Duane

 

[John Coleman]

Not that it really matters, but I realized that it probably isn't the
Exel 4 Macro displaying solver's junk (which doessn't seem as bad as
what you are reporting). Even though I can no longer figure out how, I
was able to unhide Solver's macro sheets (which are not password
protected) and they had (iirc) an auto-open() which did the sort of
registration being reflected in the immediate window, so I took that
as an explanation of what I was seeing - but I don't think such an old-
style macro sheet would have access to the immediate window.

Out of curiousity, does anybody know how to render add-in Excel4 macro
sheets visible? It's been over a year and I can't remember how I did
it.

I noticed something similar when I switched to Excel 2003. I had a
momentary fear that a virus had somehow infiltrated Excel, but I was
able to track it down to an Excel 4 macro that the Solver add-in was
using to run some initialization/registration code. I don't know what
changed between Excel 2000 and 2003 for this change in behavior in old
add-ins. I just highlight and delete - annoying maybe but over in a
second.

Help please,

I just switched from Office 2000 to 2003. Here's an example of what
I'm getting in the Immediate window.

[GetMacroRegId] 'fnWeekNum' <
[GetMacroRegId] 'fnWeekNum' -> '216727643' >

How do I get rid of this junk?

Duane- Hide quoted text -

- Show quoted text -

 

[Guest]

Chip,

Please email me directly, I have questions regarding our last conversation.

Thanks in advance,

Christmas May

The password for protected addins (either solver or the analysis toolpak)
is
there because the owner didn't want its intellectual property shared.

Actually, there is nothing to see in these add-ins. All they do is call
registered functions in a DLL. If you were to open up the XLA add-ins, all
you'd see is calls to the DLLs that do the real work, and of course the
Debug.Print statements that started this discussion. You wouldn't see any
code that does the calculations.


--
Cordially,
Chip Pearson
Microsoft MVP - Excel
Pearson Software Consulting, LLC
www.cpearson.com
(email address is on the web site)

The password for protected addins (either solver or the analysis toolpak)
is
there because the owner didn't want its intellectual property shared.

I think it's a good idea to respect that.

IIRC, this junk is left over from a "debug.print" in the analysis
toolpak.

You'd have to know the password to clean it up.

(or just ignore it???)

bigHatNoCattle wrote:

Help please,

I just switched from Office 2000 to 2003. Here's an example of what
I'm getting in the Immediate window.

[GetMacroRegId] 'fnWeekNum' <
[GetMacroRegId] 'fnWeekNum' -> '216727643' >

How do I get rid of this junk?

thanks

Duane

--

Dave Peterson

How do I get the password and specifically what steps do I take to
delete the debug code?

Duane

 

[bigHatNoCattle]

Chip,

Please email me directly, I have questions regarding our last conversation.

Thanks in advance,

Christmas May

Actually, there is nothing to see in these add-ins. All they do is call
registered functions in a DLL. If you were to open up the XLA add-ins, all
you'd see is calls to the DLLs that do the real work, and of course the
Debug.Print statements that started this discussion. You wouldn't see any
code that does the calculations.

--
Cordially,
Chip Pearson
Microsoft MVP - Excel
Pearson Software Consulting, LLC
www.cpearson.com
(email address is on the web site)

The password for protected addins (either solver or the analysis toolpak)
is
there because the owner didn't want its intellectual property shared.
I think it's a good idea to respect that.
bigHatNoCattle wrote:
IIRC, this junk is left over from a "debug.print" in the analysis
toolpak.
You'd have to know the password to clean it up.
(or just ignore it???)
bigHatNoCattle wrote:
Help please,
I just switched from Office 2000 to 2003. Here's an example of what
I'm getting in the Immediate window.
[GetMacroRegId] 'fnWeekNum' <
[GetMacroRegId] 'fnWeekNum' -> '216727643' >
How do I get rid of this junk?
thanks
Duane
--
Dave Peterson
How do I get the password and specifically what steps do I take to
delete the debug code?
Duane

- Show quoted text -

All the answers so far have yet to really solve my original question.
Here's my quesiton again.

How do I get the following junk from being written to the Immediate
window?

[GetMacroRegId] 'fnWeekNum' <
[GetMacroRegId] 'fnWeekNum' -> '216727643' >


Duane

 

[Tom Ogilvy]

unload the analysis toolpak. - don't use it.

--
Regards,
Tom Ogilvy

Chip,

Please email me directly, I have questions regarding our last
conversation.

Thanks in advance,

Christmas May

The password for protected addins (either solver or the analysis
toolpak)
is
there because the owner didn't want its intellectual property shared.

Actually, there is nothing to see in these add-ins. All they do is call
registered functions in a DLL. If you were to open up the XLA add-ins,
all
you'd see is calls to the DLLs that do the real work, and of course the
Debug.Print statements that started this discussion. You wouldn't see
any
code that does the calculations.

--
Cordially,
Chip Pearson
Microsoft MVP - Excel
Pearson Software Consulting, LLC
www.cpearson.com
(email address is on the web site)

The password for protected addins (either solver or the analysis
toolpak)
is
there because the owner didn't want its intellectual property shared.

I think it's a good idea to respect that.

bigHatNoCattle wrote:

IIRC, this junk is left over from a "debug.print" in the analysis
toolpak.

You'd have to know the password to clean it up.

(or just ignore it???)

bigHatNoCattle wrote:

Help please,

I just switched from Office 2000 to 2003. Here's an example of
what
I'm getting in the Immediate window.

[GetMacroRegId] 'fnWeekNum' <
[GetMacroRegId] 'fnWeekNum' -> '216727643' >

How do I get rid of this junk?



Dave Peterson

How do I get the password and specifically what steps do I take to
delete the debug code?


Dave Peterson- Hide quoted text -

- Show quoted text -

All the answers so far have yet to really solve my original question.
Here's my quesiton again.

How do I get the following junk from being written to the Immediate
window?

[GetMacroRegId] 'fnWeekNum' <
[GetMacroRegId] 'fnWeekNum' -> '216727643' >


Duane

 

[Tom Ogilvy]

right at the bottom of the page

http://www.cpearson.com/

is Chip's email address.

--
Regards,
Tom Ogilvy

Chip,

Please email me directly, I have questions regarding our last
conversation.

Thanks in advance,

Christmas May

The password for protected addins (either solver or the analysis
toolpak)
is
there because the owner didn't want its intellectual property shared.

Actually, there is nothing to see in these add-ins. All they do is call
registered functions in a DLL. If you were to open up the XLA add-ins,
all
you'd see is calls to the DLLs that do the real work, and of course the
Debug.Print statements that started this discussion. You wouldn't see any
code that does the calculations.


--
Cordially,
Chip Pearson
Microsoft MVP - Excel
Pearson Software Consulting, LLC
www.cpearson.com
(email address is on the web site)

The password for protected addins (either solver or the analysis
toolpak)
is
there because the owner didn't want its intellectual property shared.

I think it's a good idea to respect that.

bigHatNoCattle wrote:

IIRC, this junk is left over from a "debug.print" in the analysis
toolpak.

You'd have to know the password to clean it up.

(or just ignore it???)

bigHatNoCattle wrote:

Help please,

I just switched from Office 2000 to 2003. Here's an example of
what
I'm getting in the Immediate window.

[GetMacroRegId] 'fnWeekNum' <
[GetMacroRegId] 'fnWeekNum' -> '216727643' >

How do I get rid of this junk?

thanks

Duane

--

Dave Peterson

How do I get the password and specifically what steps do I take to
delete the debug code?

Duane

 

[bigHatNoCattle]

right at the bottom of the page

http://www.cpearson.com/

is Chip's email address.

--
Regards,
Tom Ogilvy

Chip,

Please email me directly, I have questions regarding our last
conversation.

Thanks in advance,

Christmas May

The password for protected addins (either solver or the analysis
toolpak)
is
there because the owner didn't want its intellectual property shared.
Actually, there is nothing to see in these add-ins. All they do is call
registered functions in a DLL. If you were to open up the XLA add-ins,
all
you'd see is calls to the DLLs that do the real work, and of course the
Debug.Print statements that started this discussion. You wouldn't see any
code that does the calculations.
--
Cordially,
Chip Pearson
Microsoft MVP - Excel
Pearson Software Consulting, LLC
www.cpearson.com
(email address is on the web site)
The password for protected addins (either solver or the analysis
toolpak)
is
there because the owner didn't want its intellectual property shared.
I think it's a good idea to respect that.
bigHatNoCattle wrote:
IIRC, this junk is left over from a "debug.print" in the analysis
toolpak.
You'd have to know the password to clean it up.
(or just ignore it???)
bigHatNoCattle wrote:
Help please,
I just switched from Office 2000 to 2003. Here's an example of
what
I'm getting in the Immediate window.
[GetMacroRegId] 'fnWeekNum' <
[GetMacroRegId] 'fnWeekNum' -> '216727643' >
How do I get rid of this junk?
thanks
Duane
--
Dave Peterson
How do I get the password and specifically what steps do I take to
delete the debug code?
Duane

- Show quoted text -

Your suggestion of "don't use the analysis toolpack" would certainly
work but has a high undesirable side effect of me trying to replace
the functions that I'm calling in the analysis toolpack.... with
something else.

Yes I could email Chip Pearson and I assume hire him but I admit
it.... I'm trying to get the solution on the cheap.

It's amazing to me that the 2003 analysis toolpack this problem of
Microsoft leaving debug.print code in. Hasn't Microsoft offered a
patch that removes the debug.print code??

So that things like:

[GetMacroRegId]

are not being printed to the Immediate window?


I tried to find some reference to the problem and a fix on Microsoft's
site without success.

Duane

 

[Dave Peterson]

No patches from MS for this.

right at the bottom of the page

http://www.cpearson.com/

is Chip's email address.

--
Regards,
Tom Ogilvy

Chip,

Please email me directly, I have questions regarding our last
conversation.

Thanks in advance,

Christmas May

"Chip Pearson" wrote:

The password for protected addins (either solver or the analysis
toolpak)
is
there because the owner didn't want its intellectual property shared.

Actually, there is nothing to see in these add-ins. All they do is call
registered functions in a DLL. If you were to open up the XLA add-ins,
all
you'd see is calls to the DLLs that do the real work, and of course the
Debug.Print statements that started this discussion. You wouldn't see any
code that does the calculations.

--
Cordially,
Chip Pearson
Microsoft MVP - Excel
Pearson Software Consulting, LLC
www.cpearson.com
(email address is on the web site)

The password for protected addins (either solver or the analysis
toolpak)
is
there because the owner didn't want its intellectual property shared.

I think it's a good idea to respect that.

bigHatNoCattle wrote:

IIRC, this junk is left over from a "debug.print" in the analysis
toolpak.

You'd have to know the password to clean it up.

(or just ignore it???)

bigHatNoCattle wrote:

Help please,

I just switched from Office 2000 to 2003. Here's an example of
what
I'm getting in the Immediate window.

[GetMacroRegId] 'fnWeekNum' <
[GetMacroRegId] 'fnWeekNum' -> '216727643' >

How do I get rid of this junk?



Dave Peterson

How do I get the password and specifically what steps do I take to
delete the debug code?


Dave Peterson- Hide quoted text -

- Show quoted text -

Your suggestion of "don't use the analysis toolpack" would certainly
work but has a high undesirable side effect of me trying to replace
the functions that I'm calling in the analysis toolpack.... with
something else.

Yes I could email Chip Pearson and I assume hire him but I admit
it.... I'm trying to get the solution on the cheap.

It's amazing to me that the 2003 analysis toolpack this problem of
Microsoft leaving debug.print code in. Hasn't Microsoft offered a
patch that removes the debug.print code??

So that things like:

[GetMacroRegId]

are not being printed to the Immediate window?

I tried to find some reference to the problem and a fix on Microsoft's
site without success.

Duane

 

[Tom Ogilvy]

the reference to Chip's email was to Christmas May who was hijacking your
thread. I doubt hiring Chip would solve the problem, so I wasn't suggesting
that.

--
Regards,
Tom Ogilvy

right at the bottom of the page

http://www.cpearson.com/

is Chip's email address.

--
Regards,
Tom Ogilvy

Chip,

Please email me directly, I have questions regarding our last
conversation.

Thanks in advance,

Christmas May

"Chip Pearson" wrote:

The password for protected addins (either solver or the analysis
toolpak)
is
there because the owner didn't want its intellectual property
shared.

Actually, there is nothing to see in these add-ins. All they do is
call
registered functions in a DLL. If you were to open up the XLA add-ins,
all
you'd see is calls to the DLLs that do the real work, and of course
the
Debug.Print statements that started this discussion. You wouldn't see
any
code that does the calculations.

--
Cordially,
Chip Pearson
Microsoft MVP - Excel
Pearson Software Consulting, LLC
www.cpearson.com
(email address is on the web site)

The password for protected addins (either solver or the analysis
toolpak)
is
there because the owner didn't want its intellectual property
shared.

I think it's a good idea to respect that.

bigHatNoCattle wrote:

IIRC, this junk is left over from a "debug.print" in the analysis
toolpak.

You'd have to know the password to clean it up.

(or just ignore it???)

bigHatNoCattle wrote:

Help please,

I just switched from Office 2000 to 2003. Here's an example of
what
I'm getting in the Immediate window.

[GetMacroRegId] 'fnWeekNum' <
[GetMacroRegId] 'fnWeekNum' -> '216727643' >

How do I get rid of this junk?



Dave Peterson

How do I get the password and specifically what steps do I take to
delete the debug code?


Dave Peterson- Hide quoted text -

- Show quoted text -

Your suggestion of "don't use the analysis toolpack" would certainly
work but has a high undesirable side effect of me trying to replace
the functions that I'm calling in the analysis toolpack.... with
something else.

Yes I could email Chip Pearson and I assume hire him but I admit
it.... I'm trying to get the solution on the cheap.

It's amazing to me that the 2003 analysis toolpack this problem of
Microsoft leaving debug.print code in. Hasn't Microsoft offered a
patch that removes the debug.print code??

So that things like:

[GetMacroRegId]

are not being printed to the Immediate window?


I tried to find some reference to the problem and a fix on Microsoft's
site without success.

Duane

 

[Ronald Dodge]

This issue isn't only seen in 2003, but also in 2002. However, even for
as much VBA writing that I do including having other programs
interacting with it such as Acrobat Adobe Pro or Host Access Class
Library (used to control IBM's Personal Communications program that
interacts with the main DB system), I only rarely use this immediate
window and generally only small things. If you try to use it for larger
things, you will notice that this window will only retain so much of the
last text that goes into the window while the rest of it is dropped.

I have noticed this to happen with a lot of MS's add-ins though the
Analysis Toolpak (both the regular one and the VBA one) to be very bad
about this. I do have to agree it's not a good thing to disable those 2
Add-Ins cause it means having to completely rewrite the code and I don't
look forward to doing that. It's already bad enough I have to do that
for fiscal periods, especially given the fact that management don't
stick to the same pattern, thus once every 3 years or so, I'm having to
redo the formulas, if not have it one way one year and then revert back
to the original formulas the next year. Finally, I had enough of
redoing it so much to the point that I created a stand alone module to
specifically deal with these fiscal date periods including putting in
various options.

Even though this means that I have to tie all such formulas to the set
of UDFs that I have created for these issues, it has saved me some time.
However, one major draw back to this, Excel remembers the absolute path
that you used when you created the formula to reference the UDF. This
means you can only use either the mapped drive every time or the
universal naming convention(UNC) everytime. It certainly would be nice
to be able to use relative references to the workbooks rather than just
plain old absolute references cause here's the problem when using
network drives to store files:

Most people use mapped drives, and at least within the company that I
work in, the "O" drive is mapped to their local organization folder,
which means, each user's "O" drive is mapped to the server that is on
the same site as they work at primarily (or at least considered as their
home site).

Problem with using mapped drives in larger organizations: Person A at
Site A is mapped to the their local organization folder which assume has
the file on it. Person A would be able to open it fine.

Person B at Site B is mapped to their local organization folder which is
NOT the same server, which means, Person B won't be able to use the
function cause the file isn't being located. Even if person B does open
it from the proper server, it's either via another mapped drive or the
UNC method, which is NOT the same path name as the function is
expecting.


Problem with using UNC. While the UNC would resolve the above issue,
most people use mapped drives, thus if the person opens it via a mapped
drive, the function once again won't function properly cause it's NOT
seeing the same path as the function is expecting.



Obvoiusly, I wouldn't want to necessarily have these types of files
stored on all users PCs either cause then when updates are applied, it
doesn't carry down to the PCs. It would be nice to be able to use some
sort of an indirect function to refer to such UDFs similar to how I been
able to use the "INDIRECT" function to refer to cells within specific
workbooks without regards to what network path that was used to open the
file, though this method doesn't work within Charts as Charts doesn't
allow for such functions.

The only way I been able to figure out how to get around this issue is
to setup a UDF in each individual workbook that relies on the main
workbook, but that's also undesireable for other reasons.