I'm creating an application in VBA that uses a reference from vbscript.dll
I'm trying to figure out the best way to load the library, and am having difficulty distinguishing between using a declare function (http://msdn.microsoft.com/en-us/library/aa716201(v=vs.60).aspx) or just dynamically adding it to the list of references (How to add a reference programmatically, part 2 of the top answer)
If anyone can clarify the difference in result between the two, and maybe some advantages of one, I would be very happy.
My Notes:
I like the looks of a simple declare function, for one thing it's short and looks nice. For another, I like avoiding hard coded paths unless I know the files won't be found in different places.
On the other hand, I really like the error handling in method 2.
Declare is (typically) used for calling stdcall-supported functions exported from Windows DLLs. The VB run-time takes care of calling LoadLibrary, GetProcAddress, etc. to locate and load the functions you've declared. Most of the Windows API is used this way from VB/VBA.
References are used for COM objects -- that is, libraries that define a type library and a COM interface.
It's rare for a library to support both. If what you have is a COM library (if it appears in the 'References' dialog), add a reference to it and instantiate it that way.
Related
The ABAP documentation lists three kinds of modularization structures:
Methods. Problem: methods don't accept parameters.
Function modules. Problem: FMs belong to function groups and can be called from other programs. Apparently they are meant to be reused across the system.
Forms. Problem: are marked as "obsolete".
Is there a newer structure that replaces the obsolete FORM structure, that is:
Local to our program.
Accepts parameters.
Doesn't require ABAP Objects syntax ?
Methods. Problem: methods don't accept parameters.
I am not sure how you came to that conclusion, because methods support parameters very well. The only limitation compared to FORMs is that they don't support TABLES parameters to take a TABLE WITH HEADER LINE. But they support CHANGING parameters with internal tables, which covers any case where you don't actually need the header-line. And in the rare case that you are indeed forced to deal with a TABLE WITH HEADER LINE and the method actually needs the header-line (I pity you), you can pass the header-line as a separate parameter.
You declare a method with parameters like this:
CLASS lcl_main DEFINITION.
METHODS foo
IMPORTING iv_bar TYPE i
EXPORTING es_last_message TYPE bapiret2
CHANGING ct_all_messages TYPE bapiret2_t.
ENDCLASS.
And you call it either like that:
main->foo( IMPORTING iv_bar = 1
EXPORTING es_last_message = t_messages
CHANGING ct_all_messages = t_messages[] ).
or with the more classic syntax like that:
CALL METHOD main->foo
IMPORTING iv_bar = 1
EXPORTING es_last_message = t_messages
CHANGING ct_all_messages = t_messages[].
Function modules. Problem: FMs belong to function groups and can be called from other programs. Apparently they are meant to be reused across the system.
Yes, function modules are supposed to be global while FORM's are supposed to be local (supposed to: You can actually call a FORM in another program with PERFORM formname IN PROGRAM programname).
But classes can be local or global, depending on how you created them. A global class can be used by any program in the system. So function groups can be substituted by global classes in most cases.
The one use-case where function modules can not be substituted by methods of classes is for RFC-enabled function modules. RFC is the Remote Function Call protocol which allows external systems to execute a function module in another system via network. However, if you do need some other system to communicate with your SAP system, then you might want to consider to use webservices instead, which can be implemented with pure ABAP-OO. And they also offer much better interoperability with non-SAP systems because they don't require a proprietary protocol.
Is there a newer structure that replaces the obsolete FORM structure, that [...] Doesn't require ABAP Objects syntax ?
Here is where you got a problem. ABAP Objects syntax is the way we are supposed to program ABAP now. There is currently a pretty hard push to forget all the non-OO ways to write ABAP and fully embrace the ABAP-OO styles of writing code. With every new release, more classic syntax which can be substituted by ABAP-OO syntax gets declared obsolete.
However, so far SAP follows the philosophy of 100% backward compatibility. While they might try their best to compel people to not use certain obsolete language constructs (including adding scary-sounding warnings to the syntax check), they very rarely actually remove any language features. They hardly can, because they themselves got tons of legacy code which uses them and which would be far too expensive and risky to rewrite. The only case I can think of when they actually removed language features was when they introduced Unicode which made certain direct assignments between now incompatible types syntactically illegal.
You are having some wrong information there. Don't know what system version are you in, but this info could help you out:
Methods: They actually accept parameters (should be crazy if they wouldn't). In fact, they accept IMPORTING, EXPORTING, CHANGING and RETURNING parameters.
Forms: Indeed they are obsolete, but in my opinion there is no risk in using then, almost every standard component relies in programs made out of FORMS. FORMS are a core concept in ABAP programming. They are the "function" or "def" of many other languages. They accept USING, CHANGING and TABLES parameters.
Where in the VB6/VBA project references do Array(), LBound(), and UBound() come from..? When I'm typing in code, they don't appear in the Autocomplete list (ctrl+space), they don't get autocompleted, and they must be typed out completely before the text editor recognizes them. And only when a left-parenthesis is typed will ToolTipText pop up with the command syntax. Also, they do not appear anywhere in Object Explorer.
There's probably a basic concept in play here that I'm not aware of. And it makes me wonder, what other commands/statements/keywords are hidden in the same way..? Is there a list somewhere..? I googled for info but didn't find anything, probably because I don't know what I'm looking for and using the wrong search terms.
I ask these questions because I have the habit of prefixing many VB6 built-in functions like this: VBA.Left(), VBA.Len, VBA.Instr(), and so on. But I can't figure out what reference prefeix to use with Array(), LBound(), and UBound(), or perhaps they're so basic to VB6 that they don't have one.
I do this prefixing because years ago I was working on a large project, and there were functions I was trying to use with the same name in different reference libraries. I was a newbie and it took me a while to figure out, and it was causing tremendous problems since the functions were just NOT working the way I thought they were supposed to. It was then that I developed the prefixing habit after I figured it out. It's just easier that way, and always ensures the expected functions are being used.
The reason that they don't appear as IntelliSense options (and also why they don't appear in the Object Browser) is that they aren't declared in the VBE7.dll typelib for some reason that's beyond me. The Array function is implemented in the .dll as rtcArray. The utility of knowing that is dubious, in that its sole argument is a ParamArray, which means that if you called it directly from VBE7.dll you would need to create an array to have it feed you back the same array... This partially explains why it isn't on the typelib - a COM call would need to do the same thing, and the marshaling would basically be doing the same thing as what you'd expect the function to return.
LBound and UBound don't even appear as functions in the export table, so my guess is that they are handled more like "keywords" than first class functions internally. This makes some sense, in that it's fairly trivial to check the bounds of a SAFEARRAY if you have a pointer to the automation struct (you just index into the rgsabound array at the end of it and read the cElements and lLbound from it. Again a guess, but I'd assume that this allows for flexibility in letting LBound and UBound function with both fixed length and variable length arrays. In the fixed case, the array is basically managed as a block of memory with an indexer (more like a VT_CARRAY than a VT_SAFEARRAY). I'd imagine that handling this internally was easier or more convenient than providing first-class functions.
You won't find Debug in the Object Browser either, nor its methods Assert and Print.
You won't find Statements that are used like methods, like Open, Close, Get and Put, which is why you don't get any Intellisense when you use those statements, and the syntax must be memorized.
You will find Load and Unload as members of VBA.Global, but it's not clear what they belong to otherwise, and their arguments are late-bound Objects. The VBA documentation states that Load and Unload are Statements, even though the Object Browser shows them as Methods.
Keep in mind that you can move the order of references and it will make a difference. Try moving VBA to the top or near the top of your list of references. I believe that if something else also defines a BASIC keyword, it steals it, in a sense. I once had Right disappear and because I was not aware of the order of references, had to change all references of Right to VBA.Right. It's possibly the same with the ubound, lbound, or array.
I'm programming Windows COM in C++ and I see that a lot of functions get prefixed with :: so that the global namespace version got called. Why is that?
I understand that there may be conflicts with namespaces, but does it happen so often in COM that everyone has become so paranoid that every single function now has to be resolved explicitly?
Here are some examples that I see often:
wStrLen = ::SysAllocStringLen(NULL, wStr);
::SysFreeString(str);
::CoTaskMemFree(item);
And many others.
It just puzzles me why the programmers chose to resolve namespace explicitly and why they didn't just write:
wStrLen = SysAllocStringLen(NULL, wStr);
SysFreeString(str);
CoTaskMemFree(item);
Any ideas?
No, that's not common in COM programming, not in any I wrote or studied anyway. COM itself adds few names to the global namespace, there are not that many helper functions. A common way to implement a COM interface is to use a C++ class, you can stick it in any namespace you like since it doesn't get exposed at all outside of the module. I suspect that it is just something the team whose code you saw preferred. If you saw it in a book then that's a good way to increase the odds that the book code sample can drop into an existing program without too much trouble. There's otherwise nothing wrong with it.
I am creating a COM library with Embarcadero C++ Builder. The designer for the ridl file gives several things you can add to the ridl. I think I understand all of them except for creating new "Modules". I can't find good information for it in the documentation.
What is a "Module" and what would it be used for in COM?
You say you can't find 'good information' in the documentation; what have you found? The RAD Studio help has a section specifically explaining modules, which says:
A module defines a group of functions,
typically a set of DLL entry points.
You define a module by
Specifying a DLL that it represents on the attributes page.
Adding methods and constants using the toolbar or the object list pane
context menu. For each method or
constant, you must then define its
attributes by selecting the it in the
object list pane and setting the
values on the Attributes page.
For module methods, you must assign a
name and DLL entry point using the
attributes page. Declare the
function's parameters and return type
using the parameters page.
For module constants, use the
Attributes page to specify a name,
type, and value.
Note: The Type Library Editor does not generate any declarations or
implementation related to a module.
The specified DLL must be created as a
separate project.
It seems it's specifying methods that exist in an external DLL to whatever module (EXE or DLL) the type library is built into. Exactly what that's used for... is a good question.
The module attribute is described in this MSDN Library page. It permits declaring entrypoints in a DLL. That has little to do with COM, it is just a capability of a type library. You'll find few language development environments that can use them. I think VB6 was one of them. Ymmv.
I want to call an ActiveX DLL or OLE2 object from ABAP.
I already know the syntax of how to instantiate the object & execute the methods:
data: my_object type ole2_object.
create object my_object <ole2object>.
call method of my_object <objectmethod>.
But given a particular application, how do I know if this is supported, what the values/names of ole2object and objectmethod is?
Transaction SOLE supplies a table of OLE Applications, among this is Excel.Application which I know can be instantiated as an OLE object, so it looks like you have to add the OLE2 app to this table first, but once again where can I read the data like CLSID & LibType from - is it published as part of the application?
Objects are coming from the table TOLE. Their methods and propeties are stored into table OLELOAD.
I found some time ago somes documents (this one and this one) that contained indications of how you can find the properties and methods.
Indication on the CLSID are succint, but it seems to be the value in the register with HKEY_CLASS_ROOt/CLSID that goes with the application indicated (ie VISIO.APPLICATION for exemple). If you search this application value with regedit, you'll find the corresponding CLSID.
Hope it's helping
Guillaume
In this case, you're simply using OLE2 to access a COM interface. If you're into accessing Office applications, you might want to take a look at KB222101. For other applications and libraries, you'll need the API documentation, some suitable examples (not necessarily in ABAP, VB will do just fine). a pointed stick to poke the developer with or all three of them...
Oh, and there's a tool called OLE/COM Object Explorer by MiTeC that can be downloaded for free from their website. Haven't used it myself, but it looks like it might be helpful.