|
Umm...right. I knew it was something that obvious. Need to stop trying to do something at 1am.
--------------------------------
Human stupidity is infinite.
|
|
|
|
|
There's always (hi << 16) | lo
--
Pictures[^] from my Japan trip.
|
|
|
|
|
Thanks but no thanks. Bitwise operators is one of not so many topics I've missed during my programming studies and can't catch until now
--------------------------------
Human stupidity is infinite.
|
|
|
|
|
Alex Orovetskiy wrote: There's HIWORD and LOWORD macros for retreiving but what are for setting ?
One More MAKEWPARAM
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
I am sending a report to a HID device. I have created a handle using:
WriteHandle=CreateFile
(detailData->DevicePath,
GENERIC_WRITE,
FILE_SHARE_READ|FILE_SHARE_WRITE,
(LPSECURITY_ATTRIBUTES)NULL,
OPEN_EXISTING,
0,
NULL);
I then write a report:
OutputReport[0]=0;
OutputReport[1]=1;
OutputReport[2]=2;
OutputReport[3]=3;
OutputReport[4]=4;
OutputReport[5]=5;
OutputReport[6]=6;
OutputReport[7]=7;
Result = WriteFile
(WriteHandle,
OutputReport,
Capabilities.OutputReportByteLength,
&BytesWritten,
NULL);
The first time I send a report,it works just fine. I checked the protocol analyzer and I see the report in its entirety. No problem.
The second time I send the report it hangs. I don't need overlapped I/O, as I wait for the report to finish. I am not receiving any reports from the device. Got any ideas?
Dave
|
|
|
|
|
dave siegfried wrote: Capabilities.OutputReportByteLength
What is the value of this?
"Take only what you need and leave the land as you found it." - Native American Proverb
|
|
|
|
|
i am having a problem with the linker reading a .h file multiple times, despite my use of #pragma once and #ifndef
the header file looks like this:
#pragma once
#ifndef <uniquename>
#define <uniquename>
// function declarations
#endif
why aren't these statements preventing the linker from reading this file multiple times?
what can i do?
-thanks
|
|
|
|
|
why would you want to read it more than once ?
and the link doesn't care about .h files, are you talking about the compiler ?
'nyway... it's doing exactly what it's supposed to do
the #pragma once ( Microsoft specific ) will tell the compiler that this file can only be read once.
the #ifndef/#define/#endif construct ( portable ) will let the compiler read the file once, and define a symbol, and the next time the file is read, the symbol is defined, so it will not go thrue the rest of the declaration.
what kind of problem are you experiencing ? what do you want to do ?
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
i don't want it to read more than once, thats the problem
the Linker is giving me an error that a function in the .h is defined multiple times.
i thought that both the #pragma and #ifndef/#define/#endif shoudl prevent this, but they are not
|
|
|
|
|
out of curiosity, do you have something after the #ifndef and #define ?
#ifndef _MY_HEADER_H_
#define _MY_HEADER_H_
...
#endif
( I never use #pragma once )
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
yes, i included it in my original post, not sure why it didnt show, but will do again.
the header file is a group of commonly used functions, that i got tired of copying and pasting into all my apps, so i thought i could put them all in a central .h and #include them, hence..
#ifndef CommonFuncs_H
#define CommonFuncs_H
// functions
#endif
|
|
|
|
|
You're getting a linker error, not a compiler error, therefore the preprocessor directives aren't the problem since those are compile-time things.
The error says function foo() is defined multiple times. How could that happen?
a.cpp includes commonfuncs.h and sees the definition (and the code, IIUC) of foo() . Then b.cpp includes commonfuncs.h and sees the definition and code of foo() . Now you have two functions called foo() in your obj files.
Two solutions: 1) make the functions inline 2) move the code to a cpp file, leaving just the prototypes in the header.
--Mike--
Visual C++ MVP
LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
Come quietly or there will be... trouble.
|
|
|
|
|
1) inline didnt work
2) not sure i did it right. tried it a few ways
i copied the function to a .cpp file of the same name. put just the prototype in the .h, like this?
int myFunction (int a, int b);
tried it once where i #included the .cpp in the .h, and once where i didnt.
also tried it where i put the functions in a .cpp and #included that directly, with no .h
nothing worked
|
|
|
|
|
i feel like it might help if i gave some more background info.
i've built a lot of programs in the past that required a Dialog box where you could plot a time-series, or a series of XY's, etc and zoom in and out, etc...
in the past, i would create a new class within each application, derived from CDialog, and add all the functions to it
after doing this a dozen times, i've gotten tired of all the copying and pasting, and tweaking to whatever the new app required. so i wanted to create an independent class that i could call from any app, without having to re-build each time. i created a file, GraphDialog.h, which looks like this:
class GraphDialog : public CDialog
{
public:
// member variables & functions
};
everything worked great until i wanted to do some callback functions (e.g. WM_LBUTTONDOWN). i created them using ClassView, which created a companion .cpp
the prob, i think, is that the .cpp file #includes the .h, as does MainFrm.h, furthermore, the app.cpp #includes MainFrm.h, so GraphDialog.h ends up getting called 3 times, and i see no way around this
one of the member functions wants to use a commonly used function that i placed in another external .h
when i try to #include that .h from GraphDialog.h that function shows up as multiply defined
thanks!!
|
|
|
|
|
Ok, think about this a bit. The problem is that you are ending up compiling the same function in multiple places, and then trying to link them together. The solution is to not ever have the same function defined twice. So you can do as Mike suggested and put all the functions in one .cpp file, build that, and let the linker reference them that way. You do not need to #include the function definitions anywhere though. Just compile and link 'em in.
|
|
|
|
|
i'm trying to create an indendent class that i can call from any app, since i've been using these functins over and over again, and re-writing them each time.
i can't see any way to prevent the .h from being called twice, since both MainFrm.h and the associated .cpp file must both reference it.
i tried moving the functions that it calls to a .cpp, and that didnt work. if i did #include, then i get a multiple definition error. if i don't i get an undefined symbol
|
|
|
|
|
werfel wrote: i tried moving the functions that it calls to a .cpp, and that didnt work. if i did #include, then i get a multiple definition error. if i don't i get an undefined symbol
Don't #include the .cpp file. Never #include the .cpp file. If you're gonna #include it, name it .h, but you're not gonna include this, so don't. Compile the cpp file. Link the cpp file. Add the .cpp file to your project, and let DevStudio worry about compiling and linking it. In short, treat it like all your other .cpp files!
|
|
|
|
|
I think he needs to learn about static and/or dynamic libraries.
--
Pictures[^] from my Japan trip.
|
|
|
|
|
The first thing I would do is (ummm) make sure it's not really defined multiple times. Search the files, Luke...
------- sig starts
"I've heard some drivers saying, 'We're going too fast here...'. If you're not here to race, go the hell home - don't come here and grumble about going too fast. Why don't you tie a kerosene rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
|
The guards prevent compiler to read the header file multiple times, but if you have something defined (as opposed to declared) in a header file which is included from several cpp files, the guards cannot help you with that.
For instance if in your h file you have something like
int add (int a, int b) {return a + b;}
and include it from multiple cpp file, you'll get linker errors. To avoid it in this specific case, you'll need to declare the functionsl inline:
inline int add (int a, int b) {return a + b;}
and it should work fine.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
|
static inline will work, or something is really broken with your code and/or compiler.
Anyway, why do you want to write function bodies in your header files? It's one ingredient in the recipe for code bloat...
--
Pictures[^] from my Japan trip.
|
|
|
|
|
i think you're right that my code is seriously broken. i am entirely self-taught, and this is my first attempt as creating a portable class.
i'm putting a class definition in the header. isn't that where they're supposed to be?
some of the class members are accessing functions that i use for other programs, that i'd be just as happy placing in a .cpp, but i cant make that work either. for one thing, i would then have to #include the .cpp in the .h, which i understand to be a big no-no.
|
|
|
|
|
werfel wrote: i'm putting a class definition in the header. isn't that where they're supposed to be?
You can do that, but then you'd have to tag the methods with inline, or put the method bodies within the class. It's easiest to do the latter. Kind of like C#:
class X {
void method() {
}
}; werfel wrote: i would then have to #include the .cpp in the .h, which i understand to be a big no-no.
Indeed! What you need to investigate is how to create static (.lib ) or dynamic libraries (.dll ). A good start is learning how to use and create static libraries, since there are less details to keep in mind.
Basically, a library consists of two things: header files and a .lib -file. The header files instructs the compiler at compile time that the classes and functions are available for linking. The .lib file provides the actual code and data for the linker, so that the names referenced in the header file will be bound to the corresponding code and/or data.
One could say that the linker is the part of the compiler toolkit that puts all the pieces together. The pieces are typically .lib and .obj files. The .obj files are produced by the compiler for each compilation unit. In a C++ project, the .cpp files are compilation units. If you have #include d code bodies (such as functions, not prototypes) into several .cpp files, the linker will find duplicates of the code. Since the preprocessor is basically a cut'n'paster (#include basically pastes whatever is in the inluded file), the linker can't know that the found duplicates are the same. It will have to refuse linking. This is the linker error you got.
--
Pictures[^] from my Japan trip.
-- modified at 14:59 Sunday 18th December, 2005
|
|
|
|
|