Excel 2000 VBA and the Bloomberg API
Discussion
Hello,
Have some late bound code that instantiates an object to Bloomberg.Data.1
This object is then used to bring back some information from B'Berg via the .Subscribe method
The problem is that the code hangs on the .Subscribe method if the user is not signed into B'Berg. In the background there is message box from B'Berg asking if the user wants to log in or not.
The code runs after hours and as such I don't want it sitting at the prompt. I want to be able to trap the situation and continue with the rest of the job. However the method does not raise an error. So what should I do? Is there some sort of timeout property I can set?
TIA
Have some late bound code that instantiates an object to Bloomberg.Data.1
This object is then used to bring back some information from B'Berg via the .Subscribe method
The problem is that the code hangs on the .Subscribe method if the user is not signed into B'Berg. In the background there is message box from B'Berg asking if the user wants to log in or not.
The code runs after hours and as such I don't want it sitting at the prompt. I want to be able to trap the situation and continue with the rest of the job. However the method does not raise an error. So what should I do? Is there some sort of timeout property I can set?
TIA
I'm assuming that the dll is late bound because whoever produced it didn't want the hassle factor of limiting you to an early bound lib file, and the fixed offset entrypoints in the dll that would result.
Late binding is quite a reasonable thing to do especially if you think that the code is going to be upgraded in future. I accept that it's more hassle to deal with.
It sounds like you need to make the "subscribe" call in one thread, and monitor it in another. If the bloomberg thread does not return, your moitor thread can terminate the bloomberg thread, and do whatever it needs to afterwards.
I'd accept that it's not the best approach, mainly because of the fixed period timeout, but then again if your code is late bound, a new version may well be along later, and if you get it right you won't need to compile yours again.
A more correct way to deal with this problem is to call the subscribe function from one thread and monitor it using a second thread, but instead of using a timeout, hook the messages to the bloomberg thread, and if you catch it trying to create a dialog, then you know that the connection failed.
HTH
Late binding is quite a reasonable thing to do especially if you think that the code is going to be upgraded in future. I accept that it's more hassle to deal with.
It sounds like you need to make the "subscribe" call in one thread, and monitor it in another. If the bloomberg thread does not return, your moitor thread can terminate the bloomberg thread, and do whatever it needs to afterwards.
I'd accept that it's not the best approach, mainly because of the fixed period timeout, but then again if your code is late bound, a new version may well be along later, and if you get it right you won't need to compile yours again.
A more correct way to deal with this problem is to call the subscribe function from one thread and monitor it using a second thread, but instead of using a timeout, hook the messages to the bloomberg thread, and if you catch it trying to create a dialog, then you know that the connection failed.
HTH
Hello,
Its late bound because I as the developer am too far down the food chain to be allowed a B'Berg installation. So I have to use late binding because I dont have the B'berg ActiveX DLL installed on my dev box. Seat of the pants flying here!
As to the solution for the problem; the legacy code I had to fix did not have any time out value on the object. As such the object quite happyly sat there forever waiting for user input that never came. Now that I have added the time out it all seems to be OK. Of course its going to be interesting as I can only test it in a "live" environment
Fun, fun, fun!
Its late bound because I as the developer am too far down the food chain to be allowed a B'Berg installation. So I have to use late binding because I dont have the B'berg ActiveX DLL installed on my dev box. Seat of the pants flying here!
As to the solution for the problem; the legacy code I had to fix did not have any time out value on the object. As such the object quite happyly sat there forever waiting for user input that never came. Now that I have added the time out it all seems to be OK. Of course its going to be interesting as I can only test it in a "live" environment
Fun, fun, fun!
Cuchillo said:
Hello,
Its late bound because I as the developer am too far down the food chain to be allowed a B'Berg installation. So I have to use late binding because I dont have the B'berg ActiveX DLL installed on my dev box. Seat of the pants flying here!
As to the solution for the problem; the legacy code I had to fix did not have any time out value on the object. As such the object quite happyly sat there forever waiting for user input that never came. Now that I have added the time out it all seems to be OK. Of course its going to be interesting as I can only test it in a "live" environment
Fun, fun, fun!
Good luck.....
Welcome to the world of enforced grim software!
Hope you're getting well paid!
IE has the capability to run in 'headless' (non-display) mode. In this mode operations which would normally prompt the user, fail. Perhaps Excel has a similar mode that can be used to inhibit these dialog boxes? If all else fails you might try running the Excel object inside IE; if it is displaying the dialog via its container then this might stop your object from displaying the dialog.
atomicrex said:
We might use the Bloomberg API at work, so I will have a look for you if you like?
The object model documentation would be handy thanks
... I have had a look on the B'Berg site and the two FX help files they have is not much use and you need to have the B'berg "client" to be already installed before you can install the ActiveX and code samples.Gassing Station | Computers, Gadgets & Stuff | Top of Page | What's New | My Stuff