|
Klempie wrote: Why would the mesh guids be the same (seems ridiculous to me) and how are C/C++ apps able to avoid the conflict?
Yes, I believe this is normal. DirectX10 is backwards compatible with DirectX9. Only new/incompatible interfaces will have new guid.
Best Wishes,
-David Delaune
|
|
|
|
|
That's just the thing though. The methods on the two interfaces are completely different so I'm not sure how they would be compatible. It looks like I will be forced to do what I need to without using the 10 mesh.
|
|
|
|
|
If the methods on the ID3DX10Mesh are completely different from the DX9 version (differing signature parameters, causing it to be incompatible at the binary level), then it seems ridiculous that GUIDs would be the same (as Don Box would say, it violates the basic precept of COM). And, since, I can't imagine the Microsoft DirectX Team screwing up something that obvious and simple, there MUST be another rational explanation.
Anyway, it's good to know,...I'll stick with DirectX 9,...I understand it.
|
|
|
|
|
Yup. The methods do not match up parameter wise, nor do they even match up in terms of implied functionality from the naming.
|
|
|
|
|
I want to know which window message is generated when a volume is inserted, i.e when i insert card in memory card reader's slot an autorun dialog box appears it means there must be some message that is generated when i insert memory card in the slot, I have tried WM_DEVICEARRIVED and also WMI Win32_DeviceChangeEvent but they get fired when I insert the reader into USB slot not when i change the card, but window shows auto run dialog box i want to know that low level window message that is generated when i insert or remove card form slot not the whole card reader.
sssssssss
|
|
|
|
|
|
Hello guy, you can try WM_DEVICECHANGE message, and RegisterDeviceNotification() may be useful, good luck!
|
|
|
|
|
I have a couple of questions about developing an out-of-proc (local) COM server using ATL.
I need to figure out how to make the server function as a single instance. Currently, any call by a client app to CoCreateInstance will launch a new instance of my server. Is there a macro or define that I am missing?
I am also having trouble getting QueryInterface to work properly on an exposed class. I can only get a IUnknown ptr to my object. If the client calls QueryInterface to get a different interface, I can see via traces (from defining _ATL_DEBUG_INTERFACES and _ATL_DEBUG_QI) that the QI call on my object (in the exe) succeeds, but but the refcount is only going to 1, then QI succeeds, then release is called, dropping the refcount back to 0. (I am using the singleton class factory.) The call in the client is returning E_NOINTERFACE.
I would appreciate any ideas or suggestions on where to get help.
Thanks.
Wayne
|
|
|
|
|
to get your server to be a single instance you need to modify the call to RegisterClassObjects to
hr = _Module.RegisterClassObjects(CLSCTX_LOCAL_SERVER, REGCLS_SINGLEUSE);
|
|
|
|
|
hi
I m working on this issue from months but not found a appropriate solution yet.
I had made a customized website on ASP.NET 2.0 my website.My requirement is when ever the client login to my site a(Com)dll has to registerd in his system automatically.
Can anybody suggest me the right solution for it??
how do I able to register that dll to the client end that access my website
I be highly obliged
Thank u
sandhya
|
|
|
|
|
Take a look at the tutorial - How to add ActiveX content to your web pages[^]
By automatically register, if you mean the component must be registered without notifying the user, that is a matter of security settings at the client.
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
I am using cab,msi files with this the dll is registering while i rebuild the solution.But my requirment is after hosting my site,when i requested the url the dll has to be register.
sandhya
|
|
|
|
|
Please let me know that you COM+ is need to register in GAC?
Thanks
Md. Marufuzzaman
|
|
|
|
|
Hi, all
i am quite tired in searching for any thing that can help me in hooking the drag and drop functionality of the windows, and yet i am unable to find an exact solution....
what i want to do is to check the file's name before being dropped, anywhere in my system...then allow or disallow the movement of the file according to my requirements...so i have to make a dll to hook the event being generated by the drag and drop opertaion..
there is a lot about setwineventhook() api but i am unable to understand it completely ...whether it is used to hook the event generated while dragging an object???is there any interface to use this api???is this the right way ot hook the drag and drop handler...just like to hook the copy,paste operations there is an ICopyHook interface ..???
plz tell me if i am heading in the right direction aur if not then plz direct me in the right direction....
urgently need a help..thanx in advance..
Sameen.
|
|
|
|
|
isn't there anyone who can help me.... ...plz rply
|
|
|
|
|
Hi there,
I already described my problem here.
Short description: I am using an API from an DataProvider to program a financial stock exchange analysis program. I can fill a DataStream Object provided by the external API with multible Instrument Objects. This DataStream fires events every time a new price occurs for the respective instrument on the exchange.
If there are many (>50.000) Objects in the DataStream, sometimes it will stop firing the events. It has nothing to do with my code, I already tested the code performance and it looks ok. So somehow this "COM-Server" of the external API is the reason for this behaviour. I noticed, that the problem will occur more often on systems with older CPUs. So it also has something to do with the CPU Power.
Is there any way to influence the performance of the COM Server? Something in the Network Preferences?
Any suggestions would be appreciated.
|
|
|
|
|
You don't say how you instantiate the COM Server, but if it's an out-of-process server, or a component that you access from a remote machine, and you are a client of that server, then the COM library uses the RPC protocol to transfer the data back and forth between the two machines. You might refer to: The Network Protocol[^], a chapter from the book "Inside COM+", which describes the methods COM uses to communicate with a DCOM component on a remote machine. Also, from the same book, Standard Marshaling[^], explains the actual COM Library mechanisms involved in managing the proxy and stub architecture.
If you are accessing an out-of-process server, then that is definitely your bottleneck, and not the code that you posted in the C# Forum.
|
|
|
|
|
Ok, i'm coding in CSharp. The DataProvider API is the TaiPanRealTime API which I define in the Program.cs class:
public static TaiPanRTLib.TaiPanRealtime Tapp;
so I do with the DataStream object from TaiPan, which fires the respective events:
TaiPanRTLib.DataStream TPStream;
I instantiate the Class (start the Server) in a method:
if (Tapp == null) { Tapp = new TaiPanRTLib.TaiPanRealtime(); }
TPStream = (DataStream)TPapp.DataStream;
I add the events:
TPStream.Brief += new _IDataStreamEvents_BriefEventHandler(TPBrief_Brief);
TPStream.Geld += new _IDataStreamEvents_GeldEventHandler(TPBrief_Geld);
So thats how I set up the TaiPan Application (and with it the COM Server).
I am not a network specialist, all I could learn from the link you posted is that the COM Server uses the RPC Protocol. The RPC runs in a svchost.exe process, but I don't see any performance changes of the respective processes in the taskmanager when I start my program.
But thank you anyway for your help!
|
|
|
|
|
...Sorry, didn't mean to confuse you,...but, I got the impression that you code was OK, and that you were losing data because of physical system execution limitations. You suggested that there might be some setting in Network Preferences that would increase the performance of your DataProvider. Naturally, I assumed that you were receiving your data over the wire (which is why I made the RPC suggestion).
...So, now. I'm confused. When you describe the DataProvider as an external API, what does that mean? The library exists on your machine, and you are just linking to it when compiling? Or are you using a header file that was provided by someone who developed the Data Provider, and you use that information when instantiating (with CoCreateInstanceEx, or equivalent COM library function). Are you just developing a client application, or both a server and client, and are testing it on your machine? Can you understand my confusion?
Anyway,...I'm guessing that you have it all figured out by now.
|
|
|
|
|
I am sorry about the confusion, I will try to describe it better:
TaiPanRealtime is a Financial Charting Software from the company Lenz&Partner and can be downloaded here[^]. You must have a valid account to use this software.
It features Realtime Charts, News etc which you can access through a GUI. And it also comes with a C# API, that's what I meant with 'external API'.
After installation of the TaiPanRealtime software, in my C# Project I can add a COM Reference to the TaiPan Realtime Library to access certain functions like the DataStream I described in the posts above. [I just noticed that the path to this library does not point to an *.dll file but to the TaiPanRT.exe, don't know if this is important.] When I start my program, I first have to login to TaiPanRealtime. TaiPanRealtime then connects to the server at Lenz&Partner via internet.
When i am using the TaiPanRealtime-DataStream object, the server at Lenz&Partner have to know which symbols (equities) I am interested in. This is done by filling the DataStream with symbol numbers. The server then starts to deliver current prices for the respective instruments. The Data comes over the Internet, through the TaiPanRealtime Application and finally in my program where I can analyze it.
I already talked to the support at Lenz&Partner and there is where I first heard the word 'COM-Server'. They said, the TaiPanRealtime Application stored on my computer contains this 'COM-Server' and its performance causes my problems.
If anything is not clear, please say.
|
|
|
|
|
Thanks,...that last post is MUCH more informative. Interesting program. And, apparently, you've done the correct thing, contacting the support group for TaiPanRealtime COM server (they undoubtedly get the same types of inquiries and complaints over and over).
The fact that the COM library you are linking to is an .exe file IS actually important. It indicates that the COM Server (on your local machine) runs as an out-of-process server. You can check this by finding the listing for the GUID of the COM server in your registry, and there will be specific settings that the COM library (on your local machine) uses to manage the server process. An out-of-process COM server uses a Stub and Proxy architecture to implement the marshaling of data between your client application and the existing COM server that you instantiate when you invoke CoCreateInstance for the object. There is, of cource, an overhead involved when the COM library uses this stub and proxy architecture, in terms of execution time. But, I think that your essential problem is that the data that your TaiPanRealtime COM server is transmitting is being received from a remote machine through the RPC mechanism. The overhead here (again in terms of processor clock cycles) is MUCH greater than the time it takes to execute the code to allocate and process that data from within your local client application. The RPC protocol only allows for a limited amount of data traffic.
If you want to learn more about the whole COM server and client model and the security aspects of the COM library stub and proxy architecture, I would recommend that you get a copy of Don Box's[^] "Essential COM". It's the best book on the subject.
All that information, however, won't really do you much good with your current problem of trying to increase the flow of data from the COM Server on the remote machine, that is providing you with the essential data you need for your analysis. The only suggestion that I would make (and, this seems kind of obvious) is to query for a more restricted data set, and utilize that information more effectively (by archiving it, perhaps), and updating it as it becomes available. Do you really need all that data from so many small fluctuations immediately? Can you reschedule the events so that you have a more managable Data Stream?
|
|
|
|
|
Very, very interesting answer! I tried to check the COM Server in the registry, but I am not sure if I completely understand what you meant (for what GUID I should look for, in which path etc...)
From your post I learned that the communication between my application and the COM Server is different to the one between COM-Server and the remote machine. First one produces little overhead, last one much more.
You mean that this overhead is the overhead on my machine, right, and can be influenced by a faster CPU?
What if I run 2 instances of my application, each one on a different CPU?
I will think about your last comments!
Many Thanks!
|
|
|
|
|
There is an excellent article right here at Code Project that describes clearly and in detail the registry settings that a COM component must make on the host machine: COM IDs & Registry Keys in a Nutshell[^]. Also, you can use the search capability in the Registry Editor, by supplying the GUID in its canonical form, which looks like this: {60B4140E-B0A7-4540-B744-7E1A944E8C78}
(your GUID will be a different number, of course)
This is a 128-bit unique number expressed in hexadecimal. Look in the registry key: HKEY_CLASSES_ROOT\CLSID\...for a long list of all the registered COM CoClasses available on your computer.
What I meant by overhead was the time it actually takes to execute certain instructions or a series of instructions on a computer. This is significant since it places serious restrictions on the overall performance of the software. Assembly programmers test their algorithms all the time in their quest for speed, or, what they would call 'optimization'. Typically the time it takes to execute a function is expressed in clock cycles, based on the rated speed of your processor. Generally, what I'm referring to as 'overhead' are the set up procedures (and security checks) performed by the COM Library, the creation and transmission of the Data Packets exchanged by the Standard Marshaling Architecture (stub and proxy) between your local COM Server and Client Application, and the transmission of the Data via the RPC protocol between your local machine and the remote machine, and the handling of any associated errors.
Debugging these kinds of Networking DCOM problems can be difficult, if not impossible.
|
|
|
|
|
I was googling "RPC DCOM Transmission Acceleration", and I hit this Microsoft Corporation patent description at Patent Storm: Accelerating a Distributed Component Architecture Over a Network Using a Modified RPC Communication[^]. This information is taken directly from the document and describes the 'overhead' better than I did.
"As can be expected, calling an object located on the same computer is faster than calling an object located on a remote computer. This speed difference can be due to a number of factors. The network cables are significantly longer than the leads between the processor and the memory on the local machine. Therefore, the electrical signals simply take longer to reach the remote computer than to reach the object resident in memory on the local machine. A significantly larger factor is the overhead caused by the network protocol. Each data transmission over a network must be encapsulated, and additional information must be added to the packet so that it may be transferred across the network with error correcting capabilities, and so that it may properly be decoded on the remote machine. Furthermore, each packet sent over a network may be accompanied by a flurry of additional network packets performing necessary buffer management and receipt acknowledge functions. These further packets, which comprise the network flow control, also add to the time required to send an object call over a network to a remote computer."
"An additional factor contributing to the speed difference between a call to an object resident on the same machine and one resident on a remote machine is the overhead created by DCOM and the RPC model. RPC marshals pointers and data to be transmitted across the network by reading them from the program memory and packaging them for transportation across the network. Marshaling introduces delay because it copies from program memory into an RPC buffer the element that is to be transmitted across the network. Another aspect of the overhead of DCOM and RPC are the runtime layers. The RPC and DCOM runtime layers bridge together the client and server so that the client can make remote calls to the server. This process of bridging the client and server together is known as binding. Binding information can include the Internet Protocol (IP) address, the port number, and the interface identifier (IID)."
"The combined effects of the marshaling, the additional packets of flow control, and the activities of the runtime layers result in a dramatic decrease in the performance of DCOM over a network. In fact, compared to a raw network application which directly sends data across the network, the DCOM overhead can decrease performance by a factor of three or more."
I'm thinking that there is probably a way to query the rate at which the Data is sent over the the wire in the RPC protocol, but, probably this capability resides in the Remote COM Server. It may not be accessible to your local COM server. Otherwise, I don't really have any suggestions, since I am unfamiliar with the specific COM architecture of your remote server. You could, of course, monitor the performance of your local COM server, establish a baseline for the maximum amount of data that can be accessed, and design accordingly.
A better way would be to design an algorithm that predicts small data fluctuations (based on observed patterns) and, if a cyclic or periodic correlation is evident, eliminate as many redundant data queries as is reasonable, perhaps querying less and less often if your algorithm successfully predicts the outcome of insignificant data fluctuations. I don't know, I'm not really sure what kind of data you receive, or of what significance it is to your analysis.
|
|
|
|
|
Once again, thank you very much for your input. I searched the registry for a while and looked at the properties of the respective COM object, but could not think of any way to change its behaviour in a positive way. I also had a look at the MS patent article, which was very interesting but also confusing I don't think they already implemented this new technique in one of their OS, right?
Anyway, I got an idea how to improve my algo: The DataStream Object offers the ability to remove instruments during runtime. So I can filter instruments out while analyzing. Maybe there are other way too.
At least I have to know now where to improve my application - once again, thank you very much!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
