|
thx alot, i did work! I appreciate the answer!
|
|
|
|
|
Hi,
I'm developing a driver for a usb device.
I have already a driver sample that allows me to get data from my device.
And the sample code to interact with the device is a console application.
I need to get that data into a C# program and now I don't know what to do.
I can think in some options like:
- Do this directly in the driver layer (which is a big puzzle)
- Wrap the code of the sample app in a C++ dll which I can then use in the C# side (don't know which kind of project that belongs to)
So, I was looking for some lights in order to see where I should focus my development efforts.
Any help would be appreciatted.
With my best regards,
Nuno
|
|
|
|
|
I suggest you write a DLL that exposes the functionality of your device in the API.
This is the most common way and you'll be able to use the DLL from whatever programming language.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Hi sinosoidal,
The DeviceIoControl Function[^] can be called directly from your C# application. There is no need to create a C++ DLL when you can pass information to and from a device driver with the C# language.
Take a look in your USB driver code and look for the IRP_MJ_DEVICE_CONTROL entry point. Should be something like:
DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = SomeFunction
This defines the function which processes IOCTL codes. All you need to do is define a new IOCTL code. You simply pass a pointer in the DeviceIoControl lpOutBuffer parameter and the device driver can write data into the buffer at this address. Its extremely simple.
I would recommend spending a few hours playing with the sample project at:
WinDDK\6001.18002\src\general\ioctl\
This will give you an idea about how simple communication with a device driver is.
If the data arriving on the USB device needs to fire an event to notify your usermode application you can view the sample located at:
WinDDK\6001.18002\src\general\event
I highly recommend investing a few hours experimenting with these samples. The C# language is full featured and there is no reason to write a native DLL if the parent application is managed. You can communicate with the device driver directly from your C# application.
Best Wishes,
-David Delaune
|
|
|
|
|
Hi,
Thanks for the replies. That was good news for me. I'm trying to explorer the direct connection to the USB device from C# using DeviceIOControl.
I found an example with code from an article here in codeproject.
The example, basicly interacts with an pci card, but i have seen another example of interaction, but this time with an usb device and they both start with CreateFile passing the device GUID.
However, i cant have a valid handle. I think i'm passing the right guid of the device, because i'm getting it from the driver it self.
hFileHandle = INVALID_HANDLE_VALUE;
hFileHandle = CreateFile("{00873fdf-61a8-11d1-aa5e-00c04fb1728b}",
GENERIC_READ |
GENERIC_WRITE,
0,
(IntPtr)0,
OPEN_EXISTING,
0,
NULL);
if (hFileHandle == INVALID_HANDLE_VALUE)
{
Console.WriteLine("Cannot open driver handle");
return;
}
Any tips?
Thanks,
Nuno
|
|
|
|
|
|
Hi David,
I made it! However it was a little hard to get the device name. But I made it! 
I have to try your suggestion to get the device name more genericly.
In what regards to read from the device, I'm using readfile function which was what the test app was calling, because, otherwise, I didn't knew which IO_CTL codes to use in order to invoke the request!
I'm still ambienting myself to the windows programming model.
Your help crucial guys.
Thank you very much,
With my best regards,
Nuno
PS: you'll see me again here for sure! 
|
|
|
|
|
Hello,
i am reading the BMP file.. first as you know i must read info header then file info.. and then goes the reversed RGB data... i have written a code in C to read the rgb data, reverse it in a way i want...and save every pixel color in the big array of structures... my code seems to work very good...i created some BMP images using the MS Pain, tested it with my program...and everything was fine..
BUT... when i tried to get some pictures from internet, covert those pictures to BMP format..and read with my program, i found that my program (to be exact the fread functions inside it) read a value of 0. it just doesnt work with other pics! but it works perfect with the pics created by the MS Paint!
later.... i tried to do this.. i copied some part of MS Paint pictures into another BMP files created by MS Paint! and that pictures didnt work with my pgoram either!! very strange!
so it seems to me..that when i paint something in Paint.. and try to process with my program, it reads it fine... but when i try to copy/paste different fragments of these pictures, or copy/paste fragments from another pictures, my program reads zero values!
any ideas why? whats wrong? can anyone who worked with BMP files give me a hint?
thanks alot!
|
|
|
|
|
which fread returns 0 ?
have you tried to read past the end of the file, or did you simply fail to open the file ?
|
|
|
|
|
no i read only the amount of data which is needed for the current dimension of the picture..and i did it successfully, BUT... i read all the ZERO values.. thats it.. no errors, no program crashes...nothing bad...just fread returned 0 values...
any ideas?
|
|
|
|
|
TeslaShock wrote: and then goes the reversed RGB data
Depends on the format of the bitmap. There are at least half a dozen common BMP formats, all documented.
|
|
|
|
|
well, i read more about formats...but it seems to me that i do everything right, and my pictures are 24bit so no color table should be used there. The only difference is some formats have two unused bytes or one...after the rgb data... BUT in that case...during a read i would get the corrupted data! but...i read many many thousands of rgb values and all are ZERO...
i mean its not a problem of shifting the values... it just reads zeros! but i use the same MS Paint editor! and i do the bitmap copy/paste operations with that editor only...and copy from other pics... so what could be the problem...strange... ? 
|
|
|
|
|
Hi
I designed a dialog box using "DlgProc" to handle message.
CMyDialog::CMyDialog()
{
...
GetOFN().lpfnHook = DlgProc;
...
}
UINT CALLBACK DlgProc(HWND hDlg, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
switch (uMsg)
{
}
return 0;
}
BOOL CMyDialog::OnInitDialog()
{
}
But OnInitDialog() is never called, how can I fix it
Best regards,
|
|
|
|
|
Who and why should call it?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
I have a "CButton" which pointer should be available.
I plan to use GetDlgItem() to get it. But this function only functions correctly in "OnInitDialog".
Thanks,
|
|
|
|
|
transoft wrote: I have a "CButton" which pointer should be available.
Why do you need to have the pointer available and where ? If it is in your dialog class, you could simply associate a class member with that button.
transoft wrote: I plan to use GetDlgItem() to get it. But this function only functions correctly in "OnInitDialog".
No, that's wrong. Why would that function only work inside the OnInitDialog function ? That doesn't make any sense.
I think you really need to read a good book about the MFC because it seems you are totally confused about a lot of things. We won't be able to help you unless you grasp the basic concepts firsts.
|
|
|
|
|
"Why do you need to have the pointer available and where ? If it is in your dialog class, you could simply associate a class member with that button."
From what you said, you have something to learn and they are not IN a good MFC book.
"No, that's wrong. Why would that function only work inside the OnInitDialog function ? That doesn't make any sense."
From what you said, you have something to learn.
|
|
|
|
|
transoft wrote: "Why do you need to have the pointer available and where ? If it is in your dialog class, you could simply associate a class member with that button."
From what you said, you have something to learn and they are not IN a good MFC book.
What do you mean exactly ? If you need to access your button control, why don't you simply associate a variable with it ?
transoft wrote: "No, that's wrong. Why would that function only work inside the OnInitDialog function ? That doesn't make any sense."
From what you said, you have something to learn.
Again, unless you express yourself very poorly and I didn't understand you at all, calling GetDlgItem can be called from any function from your dialog class as long as your dialog has been created. I'm sure about this because I've been using that function quite often in such situation. Besides, what would prevent this function from working if not called from OnInitDialog ? What if you call a function from OnInitDialog which call itself the GetDlgItem ?
|
|
|
|
|
Can you use "GetDlgItem" in a "Dialogbox" class' construction?
CMyDialog:CMyDialog()
{
GetDlgItem()l ---->Wrong
}
|
|
|
|
|
No, because the dialog is not created. That's what I meant in my previous message.
But maybe you could explain a bit better what you are trying to achieve and what is the reason behind that, because it feels like you are trying to find a 'hack' around something which could probably be achieved in a much simpler way.
|
|
|
|
|
It looks like you are a bit confused (and I'm too because I don't really get your question).
Are you using the Win32 API directly or are you using the MFC's ?
If you are using the Win32 API, there is no magic done for you. You will need to handle the WM_INITDIALOG message in your window procedure and call the function yourself.
If you are using MFC, what are you trying to achieve exactly here ? You need to have an entry for the OnInitDialog function in the mesasge map (this can be done through the wizard).
|
|
|
|
|
Because MFC dialogbox can not do everything you want it do for you. You have to use special "DlgProc".
You never did some programming mixing use of MFC and Win32 API?
|
|
|
|
|
transoft wrote: I designed a dialog box using "DlgProc" to handle message.
...
CMyDialog::CMyDialog()
{
...
GetOFN().lpfnHook = DlgProc;
...
}
Unless you've written something by yourself that you named GetOFN(), I hope you are aware that the letters 'OFN' in GetOFN() is an abbreviation for the OPENFILENAME struct and that your dialog should derive from CFileDialog.
Otherwise you'll have to explain this a bit further.
Regarding the use of the lpfnHook member, you'd better read the documentation[^], especially the part about lpfnHook. It clearly states that you need to include OFN_ENABLEHOOK among the flags in the Flags member of the OPENFILENAME struct.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
This part works just fine. What I need is to get OnInitDialog() called.
|
|
|
|
|
transoft wrote: This part works just fine.
What part?
Never mind.
transoft wrote: What I need is to get OnInitDialog() called.
Well, you haven't shown anything that will call your OnInitDialog().
It won't get called by magic.
What base class did you use for your dialog?
Is it really meant to be a file dialog?
What flags have you set for the Flags member of the OPENFILENAME struct?
How do you set up and show the dialog to the user? Calling DoModal()?
Why do you think you need the hook since your using subclassing? It mixes Win32 API and MFC.
The most important question is "What Are You Trying To Do"?
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
