|
That depends on what the USB device is?
USB is not a port. It is nothing like a serial or parallel port. It is a Bus, not unlike the expansion slots inside the machine. You have to talk to the device using whatever method it exposes to you. If it exposes itself as a serial device, you can use serial communication methods to talk to it. If it exposes itself as some kind of drive, you can use file methods.
|
|
|
|
|
How can I determine if it exposes as serial device or some kind of drive? It is HASP actually
(please see the updated question)
|
|
|
|
|
BY "HASP", I assume you're talking about one of these[^].
From the code you posted, it appears to expose itself as a serial device. The only way to be sure is to contact the manufacturer of it. They may even have a SDK for it to make writing code for it easier.
|
|
|
|
|
Dear Dave, please refer again to my original question. There is no SDK, this C++ project I have establishes communication with it. The only code is the one in constructor (which I posted), and then there is separate method like Write, which calls WriteFile (which I linked) - and I assume data is written either to USB or my file system (because it supports virtual HASPS also which is just file).
So my goal is to port that C++ code (which I posted) to C#. What approach should I take you think?
|
|
|
|
|
You can either rewrite the existing code, P/Invoking the functions the C code is using and rewriting the structures they use in C# (the most complicated way) or you can just rewrite using straight file and serial communication methods (simpler to write but you have no examples to work from). There is no "best" way.
|
|
|
|
|
I understand. So do you suggest:
- If the user has specified to use HASP, I use SerialPort class (from C#) for communication and its methods
- if User has specified file system to use I use just File class from C#
(So I must encapsulate this functionality in class and depending whether user uses HASP or ordinary files, I should perform that functionality inside functions, right? e.g. either ordinary Write versus write to Serial port etc.)
Did I get you correctly?
>> "simpler to write but you have no examples to work from"
What did you mean above?
|
|
|
|
|
user20044 wrote: What did you mean above?
Do you see any examples of using this HASP or the virtual HASP with normal serial and file operation methods? A little Google will tell you that.
|
|
|
|
|
Why would it be any different then using say Serial.Port to do simple read write operations, and in case of virtual HASP, to do read write operations using normal File.Write/Read methods?
|
|
|
|
|
plus isn't the code in my original question example of that? Other methods are just doing plain read/writes, with different number of bytes, etc.
|
|
|
|
|
No, your original code is serial only. What you send and receive over the serial port is the question. Does this key understand commands and responses? What are those commands? I don't need to know that. YOU do.
As for reading the file on disk....OK, you read the file, now what? What do you do with the data?
|
|
|
|
|
Dear Dave, the class I posted is like helper class to help establish communication. As I said it is using WriteFile method from Windows (to read both serial and filesystem, check this function can read both). Once I have a general means to communicate with the serial or file system - e.g., just read write methods - then I can check the functions what data they are sending to the serial, isn't it?
I understand what you mean, but in this class there are only methods like Read. Then some other class is calling this Read and passing parameters; or write thereof. Then I can see what parameters are passed to this serial from those other classes, isn't it?
This class I posted, like I said seems to be helper to send data to the serial or file system. Is it more clear now? Thanks.
|
|
|
|
|
After closer examination of your original post, it's pulling a little trick based on failure. The DCB structure is a Device Control Block[^] used in serial communication. The Win API treats files and serial comm the same, as a stream of data.
What it's doing is taking a path, to either a COM port or a file, and attempts to open that path and setup a DCB. If the DCB application to the CreateFile handle fails, it assumes the path is a file.
As has already been said, you can either use the same C code in C#, rewritten of course, and use the same trick, or you can simplify the code and just ask the user which they are going to use and go with normal SerialPort or File based code.
|
|
|
|
|
" or you can simplify the code and just ask the user which they are going to use and go with normal SerialPort or File based code."
Exactly this was my point. Thank you
|
|
|
|
|
It means I will have to duplicate code right? There are various kind of read write and query methods means I will have to write each separately for File and Serial Port classes, so be it, this is not big issue I guess?
|
|
|
|
|
user20044 wrote: There is no SDK
They did when I had to interface with the HASP dongle. You'd first have to find out what you want exactly; write to a serial port, a USB or FileSystem. The C++ code is simply writing to a serial port.
You can do the same from C#, but may be easier to translate to managed C++[^]. Using those methods from C# is also possible, as shown here[^].
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Well this code should be writing to both USB and file system, because if there is no physical HASP, there is also virtual HASP - which is just file - and that WriteFile can write both to USB(HASP) and file system, isn't it?
In C# code, can't I encapsulate such that if user chooses physical hasp, I use SerialPort class, and if not regular File methods? What do you think?
|
|
|
|
|
user20044 wrote: and that WriteFile can write both to USB(HASP) and file system, isn't it?
It can write to different ports as documented.
user20044 wrote: In C# code, can't I encapsulate such that if user chooses physical hasp, I use
SerialPort class, and if not regular File methods? What do you think?
If you are trying to convert then go for the File methods. Not the regular ones, the API call that C++ executes.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
As noted above with Dave Kreskowiak I think best is to use File methods if user chose virtual hasp and use Serial.Port if this is physical HASP
|
|
|
|
|
This class Serial Communication in Windows[^] you linked is using exact same approach as code I posted isn't it?
It seems those methods can write both to serial(what I need) and file system.
So, I need C# equivalent.
Can't I do it with Serial.Port class when I need HASP access, and ordinary File methods when I need file system access? I understand I may need to duplicate code, but I think this is easiest for me. What do you think? Thanks.
|
|
|
|
|
I don't think a file is a replacement for the dongle.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
What do you mean? Like I said there are two options:
1. There is physical USB - HASP
2. Virtual HASP- which is just a file
So in 1st case I will use SerialPort, in the second, File methods.
Isn't it?
|
|
|
|
|
Dear Expert,
What are the principles of Internet download manager?
How is it work?
I am thinking to develop program like it, what is the suitable language?
Regards,
|
|
|
|
|
I've been a registered owner of IDM for (I think) over ten years, and it works very, very well. It is also a program that is updated almost every six-weeks because of the very complex business it does of integrating into all the popular browsers. What's even more remarkable: they've never asked me to pay for an update !
On the simplest level IDM is a manager for file-downloads, but that's like saying C# is a simple tool for making applications 
It has too many other facilities and features to go into, here.
Unless you are seasoned developer with years of experience in dealing with Windows and in interaction with browsers, and a few years of your time to spend on this project, I suggest you think of another project to do.
«I want to stay as close to the edge as I can without going over. Out on the edge you see all kinds of things you can't see from the center» Kurt Vonnegut.
|
|
|
|
|
|
What does the name suggests? Internet download manager. It simply manages the processes for file downloads or other downloads that you are trying to get.
As Bill has mentioned above, the job is not just to download the file from web resource, but also to ensure that the plugin is well integrated to all of the browsers. That is the actual tasks that they have to take care of. Downloading the resource is simply an HTTP client asking for a file download. But how does it know that a user wants to download something? That is the actual job of theirs.
For example, downloading a video from YouTube, Dailymotion or like downloading an audio file when it is played from the browser (all kinds of browsers). That is the complex task that IDM does for you. Anyone can download a file, just Right-clicking on that resource and selecting "Save as...". IDM does more than that! That is what makes it "The" Internet Download Manager. 
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
