@Jelly dayum. out of curiosity, does Excel crash as well? I think this might have something to do with an exception thrown while attempting to load the config file... although the PR I merged earlier today did fix part of that problem.. ugh stabilizing 2.0 is eating my brains.
@ThunderFrame the CAD industry is moving into the cloud. OnShape for instance is rivaling the industry giants. AutoCAD has its cloud solution called Fusion360 and SolidWorks has been experimenting with something similar. I think the transition would be gradual but some in the future, people will be forced to say bye bye VBA.
Yeah, cloud-based tools like Anaplan are a threat to things like Excel, but there's just too much legacy Excel-based work to completely move away from it
@ThunderFrame Maybe, but it relies on the VBA code sending the function pointers. I also haven't figured out how to get the interface pointer for a class, but it works just fine in module code.
my 1-year subscription for the old crappy WebSite Builder thing was going to expire, so I decided to get some hosting instead, and make a real site, in .net
@Comintern well, we are able to place the cursor in a procedure and execute the "Play" CommandBarButton. That was a problem because, IIRC, it did run the code, but Rubberduck didn't wait for it to be finished. If we executed some code that passed a pointer to Rubberduck, then RD could use that pointer to execute the real test?
because I was working in an office, not in IT. That's what VBA has that everything else doesn't: a lot of the devs aren't programmers, they're office workers automating their job (and others' too haha)
@ThunderFrame Yeah, that would work. It seems like it would only need to be called once too. You could make the callback function just execute CallByName.
hmm wait yeah there's a point here: the parser doesn't know when it's out-of-sync until it reparses ...because we don't have a VBIDE event telling us the content of the codepane is changing
If the class interface changed at all, that appears to be the only thing that invalidates the function pointer. The VBE would just recompile on demand when the callback function was called.
Should is probably more accurate. I keep forgetting that there is no "would" when it comes to the VBE.
hmm, how does the VBE handle VBE CommandBarButton events that are wired to VBA event handlers? That might be a clue as to how it handles TypeLib changes...
public void PerformActionAsync(long pObj, long AddressOfSubroutine)
{
long result = 0;
//Call one.
DispCallFunc(new IntPtr(pObj), new IntPtr(AddressOfSubroutine), CALLCONV.CC_STDCALL, VarEnum.VT_EMPTY, 0, IntPtr.Zero, IntPtr.Zero, out result);
//Set up call two.
var waitforit = new Waiter {FunctionPtr = AddressOfSubroutine};
var test = new Thread(waitforit.PauseThenExecute);
test.Start();
}
VBA code:
Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)
Public Sub Callback()
Sleep 1000
Debug.Print "Still here"
End Sub
Public Function GetFunctionAddress(test As LongPtr) As LongPtr
GetFunctionAddress = test
End Function
Public Sub test()
Dim COMLib As New Class1
COMLib.PerformActionAsync 0, GetFunctionAddress(AddressOf Callback)
End Sub
Output after 1 second: "Still here". Output after 2 seconds: "Still here".
It's cool to watch in the VBE too. It switches to the wait cursor out of no-where for the second call.
public void PerformActionAsync(long pObj, long AddressOfSubroutine) {
long result = 0; Task.Factory.StartNew( () => DispCallFunc(new IntPtr(pObj), new IntPtr(AddressOfSubroutine), CALLCONV.CC_STDCALL, VarEnum.VT_EMPTY, 0, IntPtr.Zero, IntPtr.Zero, out result) );
@Comintern I don't think you need the GetFunctionAddress function - I only posted that because I thought you wanted to inspect the value from the VBA side. You should be able to just use: COMLib.PerformActionAsync 0, AddressOf Callback
Yeah, although come to think of it, it's a primative. You're probably putting the stack address in the out parameter and it goes out of scope before the lambda is done with it.
"Rather than using thread synchronization objects (mutexes, semaphores, and so forth) to control access to an object by several threads, the marshaling process for STAs translates the call into a WM_USER message and posts the result to a hidden top-level window associated with the apartment when it was created. Calls from several different threads are converted and sent to wait in the apartment's message queue until they are retrieved, dispatched, and executed on the apartment's thread. "
"This process controls access to an apartment's objects by forcing incoming calls to pass through a sort of turnstile, thereby rendering the object's interface implementations thread-safe."
What happens when you edit is that you invalidate the compiled binary. The incoming call forces a recompile, but it's doing that at the same time it's supposed to be running code. It's like running a function as you write it with VBE interop.
@Jelly Yeah. That's what I meant by old school threading.
I'm not sure how C#6 asych-await code would work with that, but that might be another option.
I had another idea about tracking the pointers. If there was a predeclared class, and RD had a pointer to it, if the VBA project was reset, then maybe we could tell that the pointer was invalid?
IIRC, the pointers for the Workbook component are constant.
public void PerformActionAsync(long pObj, long AddressOfSubroutine)
{
long result = 0;
//Call one.
DispCallFunc(new IntPtr(pObj), new IntPtr(AddressOfSubroutine), CALLCONV.CC_STDCALL, VarEnum.VT_EMPTY, 0, IntPtr.Zero, IntPtr.Zero, out result);
//Set up call two.
var waitforit = new Waiter {FunctionPtr = AddressOfSubroutine};
var test = new Thread(waitforit.PauseThenExecute);
test.Start();
}
It puts the object that will be calling dispcallfunc inside the thread, passes the parameter to the constructor, then it executes the method on a new thread.
It's a child class of Class1. This is probably a horrible example, but this will start a thread that "polls" the callback function every second indefinitely:
[DllImport("oleaut32.dll")]
public static extern long DispCallFunc(IntPtr pvInstance, IntPtr oVft, CALLCONV cc, VarEnum vtReturn, uint cActuals, IntPtr prgvt, IntPtr prgpvarg, out long pvargResult);
long result = 0;
[STAThread]
public void PerformActionAsync(long pObj, long AddressOfSubroutine)
{
var waitforit = new Waiter { FunctionPtr = AddressOfSubroutine };
var test = new Thread(waitforit.PollVBA);
test.Start();
I'm curious about the lambda though. I wonder if this works: (x) => DispCallFunc(new IntPtr(pObj), new IntPtr(AddressOfSubroutine), CALLCONV.CC_STDCALL, VarEnum.VT_EMPTY, 0, IntPtr.Zero, IntPtr.Zero, out x)
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
Still here
The only way I've crashed Excel is by hitting the stop macro button on the toolbar during the callback.
Yeah, but that doesn't matter as much as it being the Express version. I think they lock out some of the debugging tools in the non-professional version IIR.
[retailcoder/Rubberduck]retailcoder pushed commit 0fe484ec to next: fixes #2210, implemented inspection setting to determine whether or not to run inspections automatically on successful parse.
> Closes #2210 and #2194 - adds a "run inspections automatically on successful parse" inspection setting (enabled by default), and no longer accounts for parser state's IsDirty property to determine if inspections can be executed.
[rubberduck-vba/Rubberduck]retailcoder pushed commit 0fe484ec to next: fixes #2210, implemented inspection setting to determine whether or not to run inspections automatically on successful parse.
VBA Rubberducking
VBA Rubberducking