Unexpected error (35010) in SOLIDWORKS

[kaz4ikeda]

As always, I simply put MouseScroll and MouseOverControl into my SOLIDWORKS (SW) macros and added EnableMouseScroll Me in UserForm_Initilalize. After that I sometimes (not every time) get the compilation error 35010 right after I run the macros. The macros are a file-conversion macro which is rather complicated and a simple open-drawing macro. Some symptoms are:

• SW session is never influenced (such as crash) by this error. Only the macro fails to run .
• If the macro successfully start at first time, the error 35010 seems not to appear thereafter in the SW session.

I think discovered the following workarounds:

• In the file-conversion macro, removing Option Explicit in MouseScroll and MouseOverControl seems to be in effect to reduce occurrence of the error.
• In the open-drawing macro, removing Option Explicit in UserForm code-behind stops the error to occur even after once the error occurs. Resuming Option Explicit generate the error again.

This issue may be closely related to Issue #27, but the symptom is slightly different, so I open it as a separate issue.

This error has a random nature and I can't control the occurrence, but I hope some insight will be obtained.

[cristianbuse]

Could possibly be related to this

Could you check the VBA version? In the VBA IDE (VBE) go to Help and then About Visual Basic for Applications 7.1 Mine looks like this:

It seems 1131 is the trouble version while others say that this has been fixed in version 1133.

Not sure if this is relevant for SOLIDWORKS though

[cristianbuse]

Could you please add one line to the GetCallbackPtr method and then test? Simply change this:

Private Function GetCallbackPtr() As LongPtr
    Dim ptr As LongPtr: ptr = VBA.Int(AddressOf MouseProc)

to this:

Private Function GetCallbackPtr() As LongPtr
    Sin 1 'Dummy call to force compiler to 'see' the correct address
    Dim ptr As LongPtr: ptr = VBA.Int(AddressOf MouseProc)

[kaz4ikeda]

I can use SOLIDWORKS only in my office. I will try your suggestion on Monday and report the results.

My VBA version at home is 1136: and I've never seen the error 35010 at home.

[kaz4ikeda]

VBA version of SW is 1096 (embedded in SW):

VBA version of Excel is 1128:

Both of them are before 1133.

The error 35010 occured when I used the file-conversion macro even the Sin 1 line is inserted beforehand. I clicked OK button, then VBA editor showed the following line:

Then I stopped the compilation by Reset button. Restarting the file-conversion macro caused the error again. Next, I compiled whole code by the compile command in the debug menu. Then the macro successfully executed.

[cristianbuse]

Thanks @kaz4ikeda

Do you have 'Compile on Demand' turned on by any chance, in Options/General?

Also, please try this:

• Add this method to the code (just above GetCallbackPtr) : Sub DummyMethod(): End Sub
• Replace Sin 1 with DummyMethod
• Retry file-conversion macro

[kaz4ikeda]

Yes, 'Compile on Demand' is turned on (as a default setting). If this option is turned off, another frequently using macro fails to run. This macro is created by the company's SW-managing division and password protected. Maybe It has a coding mistake somewhere in its code. So I want to go with it turned on, if possible. (It would be nice if there was a way to turn it off programmatically.)

I will try your additional suggestion tomorrow.

[cristianbuse]

If this option is turned off, another frequently using macro fails to run

😆 never heard that before

I will try your additional suggestion tomorrow.

Thanks!

[kaz4ikeda]

Hi, @cristianbuse

The second try also didn't work: I also tried resuming Sin 1 with DummyMethod but to no avail.

Is your intention to correct the alignment of the stack memory? Any other idea for workaround?

Maybe I should: ask the SW-managing division member to remove the compile-time bug of the must-use macro and turn on 'Compile on Demand', or use "debug -> compile" after the error 35010 occurs once every several times of macro run. But compilation before execution may not be perfect resolution.

[cristianbuse]

Thanks @kaz4ikeda for testing!

'Compile on Demand' should be off as it leads to many side effects.

What version of SolidWorks are you using?

[kaz4ikeda]

OK, I will make an effort for 'Compile on Demand' to be off. SW version is 2023. I don't know why the version of the embedded VBE7 is somewhat old. (😪 It's time to sleep...)

[kaz4ikeda]

That was my error. SW I'm using is 2022.

[kaz4ikeda]

Thank you @cristianbuse. Following your suggestion, I asked them to debug the must-use macro and the work has done today. Now I'm using SW with VBA macro fully compiled before execution every time. One minor problem is that it has revealed that VBA editor option is shared with Excel. So If all users turns 'Compile on Demand' off, hidden bugs of many Excel macro will explode 😆 .

Anyway, I will continue to benefit from your MouseScroll modules hereafter.

[cristianbuse]

@kaz4ikeda

So If all users turns 'Compile on Demand' off, hidden bugs of many Excel macro will explode 😆 .

😆 I know - it's a mess in any other company. I recently rewrote a financial model and got it's execution speed from 2 minutes down to 100 milliseconds. Not to mentioned fixed logic bugs that make you doubt humanity 🤣

[kaz4ikeda]

Wow, drastic speed up! Using your MemoryTools?

I have been interested in that because one of my macro faced the speed problem of CopyMemory in a subclassing callback function of MonthCalendar API. I regenerate a object from its ObjPtr value and I had to take a workaround using a static object variable to reduce the usage of CopyMemory. The workaround works well but I had to prepare "Clear" method which makes the object Nothing. Remaining static object makes a program unstable.

If I can take some time to rewrite the macro (maybe not soon), I will try your MomoryTools 😃 .

[cristianbuse]

Using your MemoryTools?

No. Nothing that advanced. It was just poor quality code, with unnecessary loops, bad logic and lack of knowledge.

I have been interested in that because one of my macro faced the speed problem of CopyMemory

MemoryTools is only useful if you have many API calls.

The workaround works well but I had to prepare "Clear" method which makes the object Nothing

MemoryTools has a MemObj method which dereferences the pointer while keeping a correct reference count.

If the pointer is for a VBA class (i.e. you have a class module for it) then use the WeakReference repository for full safety.

[kaz4ikeda]

Thanks for the advice! I'll make use of them.