Application Security Loses Control

[Guest]

Hi All

I'm trying to open a workbook without running the workbook events. I have created a SetSecurity modification to 3 (ForceDisable). This then opens the workbook without executing the workbook_open events

The problem that I'am having now is that when I pass the workbooks.open(""), it looses control of the workbook & doesn't continue with the rest of the script

I have tried setting a Workbook variable during the open, without luck. Opens the file fine, but I need it to contiue with the code

I have even tried Application.EnableEvents = False, then opening the wb without the change to the security setting

Any help on this one would be great

Paul

 

[Jean-Yves]

Hi Paul,
Did you assign the workbook to be open to a variable ?
Like : Set wb = Workbooks.Open(strWorkbookToOpen)
Reeards,
JY

Hi All,

I'm trying to open a workbook without running the workbook events. I have

created a SetSecurity modification to 3 (ForceDisable). This then opens the
workbook without executing the workbook_open events.

The problem that I'am having now is that when I pass the

workbooks.open(""), it looses control of the workbook & doesn't continue
with the rest of the script.

I have tried setting a Workbook variable during the open, without luck.

Opens the file fine, but I need it to contiue with the code.

I have even tried Application.EnableEvents = False, then opening the wb

without the change to the security setting.

 

[Jean-Yves]

Hi Paul,
I didn't had problem with macro security before.
I suggest you step(F8) trought your code with the locals window open and
check the value of your variables and see if one woudl be changeg by
something (...?).
For info, what is you current degree of security ?
Good luck
Regards,
JY

Hi Jean,

I have tried:

- Setting the wb Variable as you described
- Using the Open FileDIalog.show (then . execute)
- Just trying workbook.open all by its lonesome.

All with no luck. It appears that as soon as the workbook is called, it stops the current code.

I have constructed a workaround by using the Application.Ontime method and

calling a sub-set of the code after the point where it stops.