[VB6] Modern Shell Interface Type Library - oleexp.tlb

[Elroy]

I apologize to the handful of people who've already downloaded the new 6.5 release, I forgot to include the new radio management APIs in the build list, and the source file was missing the IRadioManager interface that toggles airplane mode.

Please grab the new oleexp65-R1.zip if you originally had oleexp65.zip.

No problem, Fafalone. I (for one) appreciate all the work you've done with this thing. Also, not sure I see the problem with returning HRESULT.

[fafalone]

Thanks

HRESULT... In C/C++ there's no automatic error handling... an interface method informs you an error occurred by returning a negative HRESULT. VB consumes this and hides it for its automatic error handling system. In C/++ you have to check it yourself; in VB, VB checks it, and raises an error you can handle with 'On Error GoTo' on 'On Error Resume Next'.

The problem is VB is essentially treating every error as a critical failure with the 'GoTo' option... a lot of the time, you don't want to jump out to an error handler and abandon the entire method, for example with enumerators-- running out of items is the inevitable end of a COM enumeration. On Error GoTo sucks for that. But Resume Next, you often don't want to disable VB's natural error handling for all the VB-native code too, so you might find yourself needing to change error handling tons of times.

Personally I wish there was an option for 'Ignore errors for interfaces I've defined' option. That's what nebeln is essentially trying to do. The problem is a lot of people don't *want* to be responsible for all the error handling themselves, and VB (and tB for now) never built the special handling required to allow Implements where there's no HRESULT. (It's more complex than you'd think, after talking to Wayne about how it can be implemented-- essentially in tB when this is supported, you'll be forfeiting automatic error handling and will have to both handle internal errors yourself and be responsible for HRESULT codes returned to outside callers). Another issue is all the SDK examples are in C++, and it's tough when you're just learning how to use all these interfaces to re-architect the code you're porting to account for not doing like the SDK and handling errors with SUCCEECED but instead jumping out of the code flow. Struggled with it myself at the beginning; still forget to handle it right sometimes.

VB6 adds to the complications in that if you do leave it as HRESULT, it sometimes messes with the error info. tB has Err.LastHResult to help with this; it guarantees accuracy for the last HRESULT independent from the VB translation of Err.Number.

There's a very strong bias against OERN in the community, but I find myself more and more wanting to just use it for entire methods in oleexp/WDL-heavy calls. Especially when I don't really understand what I'm doing; like my DirectComposition example, every method is OERN so I could follow the SDK as closely as possible.