Found out that entries at HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\ that contain "verb" subkey represent OLE containers.
Like
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{GUID_HERE}\verb\
Question:
Is this necessary and sufficient condition to distinguish COM and OLEs (i.e is this trait necessary for all OLE's or not)?
OLE containers do not need to have any subkeys. In fact, they do not need to have any registry entries at all. All they have to do is implement a few predefined interfaces.
If you are talking about OLE servers, they usually implement some verbs that can be called through IOleObject.DoVerb(). They also usually implement MiscStatus.
Related
I'm not quite sure the wording I should be searching for on this.
I have a GraphQL schema which wraps a group of services using graphql-link-schema to perform the data resolution on the client side. The schema is intended to be built against a separate reference schema. How can I programmatically validate that my implementation matches the reference?
For bonus points- is it possible to determine whether a schema is a superset of another?
Thanks in advance (:
It's an interesting use case, but it's a bit unclear how validation like that would work. What causes validation to fail? Any differences between the two schemas? Extra types? Extra fields on existing types? Differences in return types? Differences in arguments or argument types?
Depending on your answer to the above questions, though, you may be able to cobble together your own validation function using the utility functions available here. Outside the main findBreakingChanges function, some of the utility functions available in that module:
findRemovedTypes
findTypesThatChangedKind
findFieldsThatChangedTypeOnObjectOrInterfaceTypes
findFieldsThatChangedTypeOnInputObjectTypes
findTypesRemovedFromUnions
findValuesRemovedFromEnums
findArgChanges
findInterfacesRemovedFromObjectTypes
If you have a reference or base schema available, though, rather than validating against it, you might also consider extending it when building the second schema. In doing so, you would effectively guarantee that the second schema matches the first except in whatever ways you intentionally deviate from it (by extending existing types, etc.). You could use extendSchema for relatively simply changes, or something like graphql-tool's mergeSchemas for more complicated changes.
I am using a program which makes it possible to customize dialogues via vbscript. Now, the form has an attribute which seems to be a vbDataObject (VarType returns 13).
How can I read the content and create a new vbDataObject to assign it to the attribute?
Don't know if this is exactly the answer, but it seems that vbDataObject's are indeed COM objects, but they just do not expose an IDispatch interface (so they're not true automation objects). As such, VBScript just isn't capable of accessing their content, since it needs an IDispatch interface for it. It just has an IUnknown interface which it doesn't know what to do with.
Passing them around should be possible, though, so if another true automation COM object can manipulate them for you (maybe there is such an object in the app designed to do this?), you could use that to make an object with the correct settings and pass that to the form.
Another option is to contact the authors of the app and ask them if they're willing to give this one object an IDispatch interface as well. Since they presumably went the length to put IDispatch interfaces on most of their objects, this omission might just be an oversight on their part.
I have a ServiceReference instance of which I want to get the name of the type it is registered as.
For example, the service may be a WordService, implemented by WordServiceImpl. I would like to retrieve "WordService". ServiceReference.toString() gives me something close to what I want ("[org.example.WordService]").
However, I'm assuming the toString() format isn't standard across runtimes. Also, I'd rather not inspect the interfaces of the implementing type to manually look for the interface, as I'd still have to randomly pick the right one in case of multiple interfaces.
Thanks in advance!
Silly, but I actually figured it out almost immediately after posting.
Retrieve the value of the objectClass property through the service reference:
String[] objectClass = (String[]) reference.getProperty("objectClass");
As you can see, this is an array of Strings. In my test cases, the first and only entry contained the provided service interface (org.example.WordService). I'm assuming multiple entries would appear if the implementation provides services through multiple interfaces.
I'm assuming this is standard OSGi...
We are using the aws-sdk for ruby, specifically AWS::Record::Base.
For various reasons we need to put records of various objects within the same domain in sdb.
The approach we thought we'd use here would be to add an attribute to each object that contains the object name and then include that in the where clause of finder methods when obtaining objects from sdb.
My questions to readers are:
what are your thoughts on this approach?
how would this be best implemented tidily? How is it best to add a default attribute included in an object without defining it explicitly in each model? Is overriding find or where in the finder methods sufficient to ensure that obtaining objects from sdb includes the clauses considering the new default attribute?
Thoughts appreciated.
It really depends on your problem, but I find it slightly distasteful. Variant records are fine and dandy, but when you start out with apples and dinosaurs and they have no common attributes, this approach has no benefit that I know of [aside from conserving your (seemingly pointless) quota of 250 SimpleDB domains]. If your records have something in common, then I can see where this approach might be useful, but someone scarred like me by legacy systems with variant records in Btrieve (achieved through C unions) has a hardwired antipathy toward this approach.
The cleanest approach I can think of is to have your models share a common parent through inheritance. The parent could then know of the child types, and implement the query appropriately. However, this design is definitely not SOLID and violates the Law of Demeter.
Is there any way for a consumer to enumerate all interfaces implemented by a given COM object?
You can try IDispatch/IDispatchEx if you simply want to know what methods are callable from your consumer.
In COM, the QueryInterface method on IUnknown is not required to expose what interfaces it may return. You ask for one based on its IID and you either get it or not. The implementation of QI in a particular COM object varies considerably although it's supposed to follow the pattern described by Microsoft here - http://msdn.microsoft.com/en-us/library/ms682521%28VS.85%29.aspx.
Dependency Walker won't show the interfaces as the only exports are DllGetClassObject, DllRegisterServer, etc (for DLL-hosted COM).
You may, as weismat says, inspect the TLB files. Many COM objects contain embedded typelibs in the resource section of the executable. With a tool such as resource hacker you can extract the TLBs and use LoadTypeLib COM functions to get a pointer to ITypeLib interface (you could use LoadTypeLib/LoadTypeLibEx directly with a COM or EXE DLL, of course).
WIth this interface you can iterate over the types contained within.
Dependency Walker might do the job for you...
http://theircorp.byethost11.com/index.php?vw=TypeLib is a free tool to examine the TBL files.