|
pallaka wrote: hRet = CoCreateInstance (Clsid, NULL,CLSCTX_LOCAL_SERVER,iid,(void**)&ppv);
As a rule, OCX is an in-proc server.
With best wishes,
Vita
|
|
|
|
|
I have read that COM+ is not portable. It is tightly coupled.
Please provide me a pointer to understand this better.
I gather that, COM+ which is a runtime environment should be tightly coupled
with the operating system.
Why I am confused is because, ultimately COM+ is based on components and
components are binary and ready to use that can move across dlls and
across machines ... so where is tight coupling?
Regards,
Net Questions
|
|
|
|
|
|
Hi Mike,
COM+ runtime environment is supported only by microsoft.
With regards to the component that I create say using the ATL languange or C++, can it or not run on other platforms?
Regards,
Net Questions
|
|
|
|
|
Disclaimer:
I've been breaking into developing via the C# language for about 7 months now, so take it easy on me.
I am writing an add-in to a 3D CAD program called Autodesk Inventor. It has a COM API and they (Autodesk) provide a nice project template to start from which includes the proper references as well as some pre-baked code to get you started. I have been succesfully coding against it for a couple of months now and I have decided to try out the new C# 4.0 language features that just came out with VS 2010. I'm really liking the named and optional parameters, but I digress.
When debugging, I start up an Inventor.exe session which, in short, looks to the registry and finds my add-in and loads it. The problem I'm having is actually hitting a breakpoint in my code while debugging. I have gone through several different property settings on the referenced InventorInterop.dll as well as options on debugging (among other trial and error things), none of which seems to work. The only thing that works is when I go back to an earlier .NET framework (i.e. not 4.0).
I have tried this on other *sample* add-ins that come with the SDK and the same thing happens. The add-in loads and code gets executed, but the breakpoints don't get hit when targeting the .NET 4.0 framework.
Is this a problem with me, the COM interop, or something else altogether?
Thanks in advance.
-Brian Hall-
|
|
|
|
|
Hello Folks,
I'm working on a C++ project that requires me to unmount and remount volumes on a flash drive, and from what I can tell, the system services I need to access are implemented using COM.
http://msdn.microsoft.com/en-us/library/cc227526(v=PROT.10).aspx[^]
I believe that I am supposed to create an IVolumeClient object using CoCreateInstance, and then use that object to communicate with the Disk Management server.
My confusion comes when I try to find any kind of interface to IVolumeClient on my development machine. Where would I find a C++ header file for the IVolumeClient interface, and where would the proper CLSID and IID values for CoCreateInstance be found?
Thanks for your time,
Ron Aldrich
|
|
|
|
|
Good Question. I've searched the whole DDK, and I can' t find one. the Interface is however defined in full (including CLSID) in the open specification you refer to (look in Appendix A, 6.1 full dmintf idl)
May I however suggest another (supported) approach to this: (the open spec is for information only)
Starting with server 2003, you can use WMI to mount/unmount volumes : http://msdn.microsoft.com/en-us/library/aa392400(v=VS.85).aspx[^]
The thing that confuses me is that the documentation states: no client operating systems supported, but this may be an artefact of the age of the documentation (the documentation may not have been updated since this function was implemented, and this may only indicate that at the time of the implementation, there were no clients supporting this).
If all else fails, you can always use the mountvol.exe utility, have look at the answer in http://www.codeproject.com/Messages/3443352/Re-How-to-get-the-hidden-drives-in-windows.aspx[^] (I believe mountvol uses WMI, that's why I think it's supported in Vista and Windows 7.
If you have to go beyond server 2003, you could use FSCTL's to do your mounting, have a look at this article:
Inside Mountvol.exe[^] Although this primarily deals with registering the reparse points as a normal user. (this can't be done, for security reasons), however the drive letters (a: b: c: ...) are pre-existing, so they require no privileges to mount. Running you program as administator will help anyway (always needed for the registration of a reparse point).
A lot of this is educated guesswork (I haven't tried it) but this should set you on your way...
|
|
|
|
|
Thanks Michel,
That helps, but I'm still not sure I'm looking in the right area.
Here's my problem:
I'm changing the write protect state on a USB flash drive, using vendor unique SCSI commands. In order to do so safely, I'm looking at 3 (or four) steps.
1) Unmount the drive's volumes (Hopefully this will be adequate to insure that all caches are flushed).
2) Change the drive's write protect state (vendor unique SCSI command).
3) Remount the drive's volumes.
It's possible that I'll also need an additional step.
2b) Somehow, magically, convince the drive's device driver that it needs to reestablish its write protect state.
Now for the hard part:
All of this has to work on Windows XP, Windows NT and Windows 7. Support for Windows Server flavors is optional.
Ideally, this has to work on a user account, without administrator privileges.
I guess my first task is to determine whether or not this is even possible.
Thanks for your time,
Ron Aldrich
Software Architects, Inc.
|
|
|
|
|
WOW, who sold you this job? were you sober?
Taking it in order.
1) Unmounting the drive will flush the caches. Of course the SCSI standard allows surprise removal so, you never can tell.
2) Issuing SCSI commands. You should be able to issue any SCSI custom command through IOCTL passtrhru interface if the drive is not mounted. How this is affected by security and passwords, I'll be honest: I don't know. You may well require elevated priviliges to do this from user mode.
3) Remounting volumes: should be no problem if you have chosen a drive letter or a reparse point previously. If the drive (well the drives's GUID, really) has not been mounted before, you need elevated privileges to put in the HKLM section of the registry. Also take a look at the automount status (which I think you can see in mountvol, or diskpart. (not too sober myself)).
2B) reestablish write protect. Well I suppose there's a custom SCSI for that one too? Of course if your thingy i s already mounted, you may require elevation. Scratch that, if your drive is already mounted R/W, write protecting it afterwards will cause the file system driver (FAT32, NTFS) to have a nervous breakdown. You won't believe how these things can fill your event log with messages of doom.
Ron Aldrich wrote: All of this has to work on Windows XP, Windows NT and Windows 7
Which Windows NT? If you're talking about 3.1 or 3.51, I've worn out the CD's to put my ashtray on. (Actually I seem to remember they still came on floppys). Windows 2000 has left supported status when William Shatner had to hand over the keys of the USS Enterprise. Your best bet is XP service pack 3. It postdates server 2003 (when all the goodies were introduced) and should have all the nice OS interfaces, without having to write your own device drivers.
Without user privileges: actually I think this is feasible, providing that you have an install program that handles the messy bits like doing initial mounts, establishing HKLM keys.
Ron Aldrich wrote: I guess my first task is to determine whether or not this is even possible.
Funny you should say that. Today I gave some advice to a rookie, which was exactly in line with what you're saying now. Of course I'm not implying you're a rookie, but this might amuse you: http://www.codeproject.com/Answers/76089/this-is-a-network-analyzer-how-do-i-Dnslookup.aspx#answer3[^]
If you're really looking at targeting pre-XP SP3 releases then the Open Specification document to which you referred may be be your only chance. But remember that these open specifications are not cast in stone. These docs were only produced by M$ because they were forced do to so by the EU. Support will be patchy, at best.
Good luck
If you send me a private reply on this message, you'll get my email address by returning mail. (putting addresses on the internet is never a good idea. (Can I interest you in some Cialis or Viagra?)
PS, to clear some confusion: you don't mount a drive. A drive is a physical thing which contains partitions. A drive is either offline or online. When it's online it can be controlled by the device manager. Partitions can be mounted or dismounted on reparse points (drive letters, empty NTFS directories) when the drive is online...
|
|
|
|
|
Hi,
I am working on a plug-in for IE that can capture and manipulate requests, before sending them to server, just like Tampar IE.
Kindly provide some help in this regard.
A step-by step would be highly appreciated as I am a novice in this domain.
TIA
|
|
|
|
|
|
I have a COM Class in Vb.Net the code is like this
<comclass(class1.classid, class1.interfaceid,="" class1.eventsid)=""> _
Public Class Class1
#Region "COM GUIDs"
' These GUIDs provide the COM identity for this class
' and its COM interfaces. If you change them, existing
' clients will no longer be able to access the class.
Public Const ClassId As String = "74eb4206-6063-4ea1-b499-bfdd9f49f4bf"
Public Const InterfaceId As String = "ff2cdb8a-e1f9-464b-bb6f-ead5812d3630"
Public Const EventsId As String = "a8880b84-9a33-41f2-90f6-c6141835ee61"
#End Region
' A creatable COM class must have a Public Sub New()
' with no parameters, otherwise, the class will not be
' registered in the COM registry and cannot be created
' via CreateObject.
Public Sub New()
MyBase.New()
End Sub
Public Function MergeFiles(ByVal arrFiles() As String, ByVal strOutputFile As String) As String
End Function
End Class
When imported in VC++ (6.0) we are not able to get the function out. Any suggestions
|
|
|
|
|
Hmmm - you're using VB.NET but still using VC++ 6.0? That makes no sense what so ever...there's so much good support for importing COM objects easily in later versions of VC++...look up #import....
Open the type library for VB.NET DLL in the OLE/COM Object Viewer (open the Type Libraries branch of the tree view and select your project's type library - it'll be named after your project) to see what interfaces and classes the DLL exports. This'll show the DLL is properly registered and also show you what object you have access to.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
CodeProject MVP for 2010 - who'd'a thunk it!
|
|
|
|
|
I'm using VC6 and the MapWindowGIS control, MapWindowGIS.OCX. It has many interfaces but few examples on how to use it using VC6. I'm kind of new to using COM so my terminology is probably incorrect to some degree.
The problem is I can get to one of the interfaces, IShapeFile, using their example using:
IShapefilePtr* pShapeFile = new IShapefilePtr;
HRESULT hr = pShapeFile->CreateInstance(__uuidof(Shapefile));
CreateInstance(), but when I try this on other interfaces such as IGrid and IGridHeader, CreateInstance() fails with the "Class Not Registered" error (0x80040154).
Since, the control, MapWindowGIS.OCX is registered, and I was able to get the IShapeFile interface, I'm assuming that I need to call QueryInterface() but the IGrid and IGridHeader interfaces are not part of the IShapeFile interface. So, I'm assuming then I need to get a pointer to the MapWindowGIS control but I'm not instantiating it directly since it is #import(ed).
VC6 created the .tli and tlh files and a CWnd derived class from the OCX called, CMap1. Is there something I can call in CMap1 that will return the main object's interface pointer so I can then call QueryInterface()?
|
|
|
|
|
JohnnyG wrote: I was able to get the IShapeFile interface, I'm assuming that I need to call QueryInterface() but the IGrid and IGridHeader interfaces are not part of the IShapeFile interface
No, but you normally would get, say, an IGridHeader interface by using the IShapeFile interfaces method QueryInterface asking it for an IGridHeader interface. All interfaces inherit from the base interface IUnknown which has three methods, QueryInterface being one of them. Having got one interface you can then use its QueryInterface method to get another interface implemented by the object.
|
|
|
|
|
Well, I'm kind of at a loss because I tried that with the IShapeFile interface (meaning I called QueryInterface for the IGrid interface on the IShapeFile interface) and I'm getting the E_NOINTERFACE error. That is why I was asking about how I get a interface pointer from the OCX control itself.
All of the examples are for VS 2008 in C# and VB.net. The only example they provide for VC6 is for creating a map using a shapefile hence, the IShapeFile interface.
I have the CLSID for the OCX is there some way I can get its main interface or IUnknown interface from the OCX using this CLSID ??
modified on Monday, April 26, 2010 5:19 PM
|
|
|
|
|
A search took me to the Mapwindow Wiki [^] where it says "An ESRI grid manager object provides functions which facilitate using ESRI grids with MapWinGIS". So it sounds to me as if you should be looking to work with the GridManager before trying to get an IGrid or IGridHeader.
|
|
|
|
|
Hello,
I need to write a stub(module), when given some PE (DLL/EXE) as input , it should give the information that this PE is Win32 DLL/EXE or COM DLL/EXE? I need it programatically to determine this.
Is there any windows APIs?
Regards
Usman
|
|
|
|
|
A normal COM dll will have the the following exported functions:
Out of these, DllGetClassObject is the main one.
Use the GetProcAddress[^] to test for the presence of these functions.
Telling if an EXE is a COM exe is not really practical.
Steve
|
|
|
|
|
Yeah..!!
This one can be a good alternative.
But its rather an out of the way we need to go. I think there would be some other straight froward methods might be available to have this information. like some flag or bit that will tell us about whether its COM PE or simple Win32 DLL /EXE
|
|
|
|
|
No, there's not. A DLL, an EXE, a COM-DLL and a COM-EXE are all PE files. There is nothing magical about COM components as far as PE files are concerned.
Steve
|
|
|
|
|
More over DLL Exe won't have these methods.
and what if user define its own methods with these names in WIN32 DLL's and WIN32 EXE's.
I think there would be some more generic way out to check whether these are COM EXE,COM DLL's OR Win32 EXE's or Win32 DLL's.
Regards
Usman
|
|
|
|
|
There's nothing special about a COM exe. In general you'd call a DLL a COM-DLL if:
- It's registered.
- It exports
DllGetClassObject.
For an EXE:
- It's registered.
- When ran it calls CoRegisterClassObject[^]
to hook up its class objects to the COM runtime.
Notice that registration is not a property intrinsic to a PE file. Also there are ways a PE file could be considered a COM module and not even do all of the above:
- It could implement COM objects and make them available via some factory method. This pattern is used quite frequently.
- It could use some other method to make its objects available, such as the running object table.
- Even DLLs can use
CoRegisterClassObject to make its class objects available. I've used this technique to implement registration-free COM many times.
There are no magic flags and none are needed.
Steve
|
|
|
|
|
Try registering and look at the result? Or search the COM registry area for a reference to that dll/exe?
|
|
|
|
|
Why do you need to do this?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
