You're right. I was able to reproduce this very large delay whenever I use a menu in a multithreaded application, if there are threads in the application that are not processing events, nor sleeping, at the time the menu is operated the first time.
I debugged the problem and tracked it down to a call that CVI makes to the multimedia SDK in order to play a system sound that is associated in the OS with opening a menu. Even if in most cases, there is no sound association.
The problem seems to happen because multiple DLLs are loaded at that time, and in the process of loading those DLLs, Windows need to send several messages to each thread in the system. If a thread is essentially blocked from responding to messages, this slows down the process considerably.
I realize that this is definitely a problem, and the next version of CVI should hav a fix for this, somehow. In the meanwhile, if you are able to put some code in your secondary thread to sleep periodically (the SDK function
Sleep), or process events periodically (the CVI function
ProcessSystemEvents) that should improve the response a fair amount.
Luis
NI