Hi Giovanna,
It’s not a problem I have seen reported before, though it is a tricky bit of code that implements the relevant part of Excel-DNA.
The warning you see from Excel-DNA will occur if the message queue is full for an Excel-DNA internal window used to set up the call back to Excel.
The error code 1816 is returned from an internal call to the Win32 PostMessage API, and is a fairly generic error that has the description "Not enough quota is available to process this command." But in this context it just seems to meant that the message queue is full.
It is unlikely that Excel-DNA code is filling up the message queue on this window, even with many QueueAsMacro calls outstanding.
However, other code running in the Excel process (including Excel itself) might also be posting message to the queue.
While Excel is busy, the queue would not be services, so any such messages from elsewhere could pile up and cause the error.
The one thing you can check in your code is that you are never calling to the COM object model from another thread (or process).
Such calls all have to pass through the main thread’s message queue, and so might be interfering.
The intention behind the QueueAsMacro mechanism is to ensure you can run code on the main thread.
The code you show seems OK, but you suggest there is other work going on in parallel somehow.
If that other work is talking to the Excel COM object model, it _must_ be running on the main Excel thread.
Excel-DNA does try to handle this situation correctly, and will retry the work later. So this Warning message shows that something has happened, but it is not an error and your code should still execute correctly.
With the default logging settings, you would not normally see this warning (since the LogDisplay is only shown if there is an error).
Are you showing the LogDisplay yourself, or is there a later error message also?
If you want to investigate further, you might want to find a simple situation which recreates the problem.
Perhaps can you make a new tiny add-in with some of the slow calls and some QueueAsMacro work that would be outstanding.
This would allow me to have a closer look if I can then reproduce on my machine.
You might also test that you can recreate the problem with a simple add-in, running in Excel with no other add-ins running, on a Windows instance with nothing strange running.
-Govert
--
You received this message because you are subscribed to the Google Groups "Excel-DNA" group.
To unsubscribe from this group and stop receiving emails from it, send an email to exceldna+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/exceldna/af72d416-d3f5-4970-b970-2007a5695b67n%40googlegroups.com.
With the default logging settings, you would not normally see this warning (since the LogDisplay is only shown if there is an error). Are you showing the LogDisplay yourself, or is there a later error message also?
If you want to investigate further, you might want to find a simple situation which recreates the problem.
Sure, I will try to recreate exactly as you told me and I get back to you tomorrow (if I had success or not hehe).
Kind Regards,
Giovanna
If you don’t have a special App.config file in your project (or <MyAddIn>.xll.config file in the output) then you’ll be running the default logging configuration.
In this case the user should only have seen the LogDisplay window if there was some error that occurred, in addition to the warning you post.
That error might be more important than this warning.
By setting up an app.config file as described in the Diagnostics logging wiki you point to, you can also write warnings and errors to a log file – that might help you monitor the situation.
I think Verbose logging will be too much, though. You should check in your environment.
To view this discussion on the web visit https://groups.google.com/d/msgid/exceldna/0f14f955-2354-4639-a98d-02298e253fb9n%40googlegroups.com.
HI Giovanna
Given Govert’s answer regarding the message queue being full, how many concurrent requests are you queueing before this ‘fails’? Looking at the code posted, the methods used in WebRequest are blocking calls, so perhaps using their Async counterparts may help. I have not used the ExcelAsyncUtil before so am not sure if this will make a difference. Also the WebRequest class is not recommended to be used by Microsoft anymore, in favour of HttpClient, however, I do understand that for corporate work you may not be in a position to make that sort of change.
For some more logging you can wire up a tracewriter (I use Serilog FileSink) to capture any additional information for debugging your clients issues.
One advice I may give, is that I’d try and separate the data gathering from the presentation/calculation logic. I have done realtime web sockets excel plugins for financial services before and favoured RTD as the middleware mechanism between the socket server, data cache and excel sheet. This can isolate any latencies or issues you may encounter on the request side of things. Sockets based programming is more reactive, but since you mentioned the history function, it may not be relevant directly. I’d still try and keep the http requests as seperated as possible from the main excel thread and favour the use of the async methods to limit/mitigate any blocking.
Hope that helps
Craig.
To view this discussion on the web visit
https://groups.google.com/d/msgid/exceldna/ed77ed9b-dfff-4e6c-bb8a-9ae7da36a0b8n%40googlegroups.com.
HI Giovanna
With regards to RTD, I only mentioned it as sometimes I see people doing many calls to Http service and it causing them issues. From what you have described and your use case I agree it could probably complicate things unnecessarily since you are only doing small amounts of calls. My only suggestions at the moment are to try and add some logging into the FetchHistoricalData method to see how much it is getting called to try and isolate the problem.
Thanks
To view this discussion on the web visit
https://groups.google.com/d/msgid/exceldna/45a2a3c1-1c0e-4e13-93a6-93ffe14edff4n%40googlegroups.com.