|
The bytes received is the same as the prior call of WSARecv which return 0;
|
|
|
|
|
flawless on normal non-acceptex sockets? have both client and server code?
Kuphryn
|
|
|
|
|
I've sent the code to you.
Please check.
|
|
|
|
|
Looked code
question refers to code inside operation == SOCK_OP_ACCEPT?
Kuphryn
|
|
|
|
|
Yes, the probelm is if WSARecv(...)==0 (the data is received), GetQueuedCompletionStatus will be unblocked unnecessarily.
|
|
|
|
|
I have prototype in my Activex control as below and i am passing a class object from client application which has some member variables
void VRMControl::SetVariant(VARIANT VariantParam)
{
}
How can i convert this variant "VariantParam" paramter to my class type so that i can able to access those member variables. More over i can able to create object for that class in my Activex page so it should able to do right?. Please explain me how to type cast it.
|
|
|
|
|
sivaprakashshanmugam wrote: How can i convert this variant "VariantParam" paramter to my class type
The short answer:
You can't; this isn't and shouldn't be possible. COM (and therefore ActiveX) is interface based and language neutral and as such doesn't know anything about C++ classes: all it knows about is COM interfaces. Let’s imagine what would happen is this was done: COM objects are meant to be able to be used by any (COM compliant) language - If your COM object required a C++ class as input how can a client of another language, such as VB, possibly use it?
The long answer:
There are various hacks that can be used to work around this for inproc COM objects but they're dirty and result in a COM object that is only usable from C++. I'm not going to go into these techniques however because they are dirty hacks and there seems little point of going to the trouble of making a COM object but breaking the COM rules so you don't get the benefits of using COM; such as language neutrality.
The correct solution to this problem is to pass an interface to the method and don't expect to be able to pass a C++ object. You can make a C++ object which implements this interface (or a VB object that does for that matter).
Steve
|
|
|
|
|
How can i pass Interface method in this; it doesn't allow me to do it. Since it provides parameter data types as standard not our own. Is there any possibilities to do this please let me know it will be much better solution for me.
|
|
|
|
|
sivaprakashshanmugam wrote: How can i pass Interface method in
You don't. As always, you pass in an interface pointer. The called method calls whatever functions it needs to from the interface.
No offense, but you need to learn some COM basics or you’ll end up making a mess.
Steve
|
|
|
|
|
hi!
im making an app that gets image from a TWAIN Source. When scanning using 24-bit RGB mode, the raw data i get is in the order R G B.
However, it seems like GDI+ uses the order B G R. Anyone have an idea how I can easily/speedily swap these bytes? The data can reach a few dozen megabytes.
Thanks!
|
|
|
|
|
Use
DG_IMAGE / DAT_IMAGENATIVEXFER / MSG_GET
this source store image in BGR format in the buffer.
Regards
Anil
|
|
|
|
|
i AM using imagenativexfer. the data i am getting is RGB.
|
|
|
|
|
Hi
According to TWAIN specification
Notes:
· Do not use BITMAPCOREINFO or BIMAPCOREHEADER as these are for OS/2
compatibility only.
· Always follow the BITMAPINFOHEADER with the color table and only save 1, 4, or 8
bit DIBs
· Color table entries are RGBQUADs, which are stored in memory as BGR not RGB.
· For 24 bit color DIBs, the "pixels" are also stored in BGR order, not RGB.
· DIBs are stored ‘upside-down’ - the first pixel in the DIB is the lower-left corner of the
image, and the last pixel is the upper-right corner.
· DIBs can be larger than 64K, but be careful, a 24 bit pixel can straddle a 64K boundary!
· Pixels in 1, 4, and 8 bit DIBs are "always" color table indices, you must index through
the color table to determine the color value of a pixel.
Regards
Anil
|
|
|
|
|
Thanks for answering!
I got a little confused. I'm sorry.
I mean I was using the buffered transfer mode.
ICAP_XFERMECH, TWSX_MEMORY
This is because the images can get really really really large.
For ImageNativeXfer, you are right. It returns the proper Bitmap. However ICAP_XFERMECH, TWSX_MEMORY returns RGBs.
I've found a possible solution of using ColorMatrixEffect in GDI+....if only Microsoft REMEMBERED to include GdiPlusEffects.h in the SDK.
Do you have other ideas?
|
|
|
|
|
Hi everyone,
i dont have any experience in VC++.I know some C and C++, thats all.May be silly,but out of curiosity I am asking this question.
If we delare a pointer as
int * p ,it will create an integer pointer p.It will reserve 2 bytes in memory also.How this two memory locations and *p is tagged together or who is allocating these memory locations to p(Like,the rule p should hold only addresses).
say the locations are 1000 and 1001.
consider this, and please check my interpretations are correct or not;
int j;
*p=2; // integer 2 is stored in 1000 and 1001 as(0000 0010)
(will this work .here p does not hold any address value and storing value 2 directly in their address space)
printf("%d",p) //prints 1000
p=&j; // now doubt,here how 1000,1001 store the address of j
j=4; // *p and j will print the same value.
Please give your comments about this or please direct me if you know some good stuffs regarding the memory concepts in programming.
Thank you
-- modified at 0:55 Friday 26th May, 2006
|
|
|
|
|
|
It's all pretty simple, once you get the hang of it.
When you declare a pointer, the compiler allocates a certain number of bytes (depending on the platform) on the stack. The size of the pointer is derived from the maximum address space that it can point to. In a 32 bit environment running Windows, each process gets 4GB of address space, so a pointer must be big enough to point at any address from 0 to 0xFFFFFFFF. The size of the pointer is therefore log2(4294967296), which is equal to 32 bits. You can do the same calculation for a 64 bit environment.
This memory allocated by the compiler holds the address of whatever the pointer is pointing to, at runtime.
jithAtran - ii wrote: *p=2; // integer 2 is stored in 1000 and 1001 as(0000 0010)
I don't get what 1000 and 1001 are. If you consider them to be address of the pointer itself (&p), then your comment is incorrect. If you consider them to be the address where the pointer is pointing at, then your interpretation is correct. I'll assume you meant the latter.
jithAtran - ii wrote: p=&j; // now doubt,here how 1000,1001 store the address of j
All this does is change where p is pointing at. p will no longer hold 1000/1001, instead, it will hold whatever is the address of j (2000, 2001, for example). That explains why *p and j hold the same value.
Regards
Senthil
_____________________________
My Blog | My Articles | WinMacro
|
|
|
|
|
Thank you Senthil,
for the detailed reply.
S. Senthil Kumar wrote: jithAtran - ii wrote:
*p=2; // integer 2 is stored in 1000 and 1001 as(0000 0010)
I don't get what 1000 and 1001 are. If you consider them to be address of the pointer itself (&p), then your comment is incorrect. If you consider them to be the address where the pointer is pointing at, then your interpretation is correct. I'll assume you meant the latter.
No I assumed the address of P itself as 1000/1001.what will happen then if we do * p=2;
S. Senthil Kumar wrote: jithAtran - ii wrote:
p=&j; // now doubt,here how 1000,1001 store the address of j
All this does is change where p is pointing at. p will no longer hold 1000/1001, instead, it will hold whatever is the address of j (2000, 2001, for example). That explains why *p and j hold the same value
I know both p and j hold the same value.
I think I should state my silly doubt more clearly,
if p is a ponter it should hold the address
p=&j //should hold the address 2000/2001 as in your example.
the address of p is 1000/1001 and how it store the addresses 2000/2001 in bit format considering 1000 will hold 4 bits and 1001 will also hold 4 bits
Thank you again.
|
|
|
|
|
jithAtran - ii wrote: the address of p is 1000/1001 and how it store the addresses 2000/2001 in bit format considering 1000 will hold 4 bits and 1001 will also hold 4 bits
Like I said in my previous post, the size of a pointer is dependent on the platform. And address is different from the size of a variable. On Win32, a pointer is 4 bytes. If the address of p is 1000, then bytes 1000, 1001, 1002 and 1003 will be available for p. 4 bytes is equal to 32 bits and 232 is the maximum address value you can point at.
Taking your example, assuming a 16 bit environment, then the address of p will be 1000 and it will have two bytes allocated to it, 1000 and 1001. A byte is 8 bits, so 1000 can store 8 bits and 1001 can store 8 bits, for a total of 16 bits. For storing 2000, depending on the endianness, the compiler might do
<pre>
_________________
__00___|___7D_____
1000 1001
</pre>
7D is 2000 expressed in hex.
Does this answer your question?
Regards
Senthil
_____________________________
My Blog | My Articles | WinMacro
|
|
|
|
|
Thanks for the reply,
Now I am getting some clues about this and I am recalling my digital electronics lessons.Dont mind when I ask about the basics.I am more with asp.net
S. Senthil Kumar wrote: A byte is 8 bits
Oh...it was my mistake But I knew that
Now the only doubt would be about the declaration.
int *p ,float *q //integer pointer.
int i // normal integer.
regardless of the datatype compiler would allocate 4 bytes to p and q.
say 1000/1001 holds an address where an integer is stored.Where would the information about the data type be stored.
since 1000/1001 stores only points to some address location where the information regarding "*p='c' should not be allowed" willbe stored.
Does the compiler holds anything like a stack to store the datatype?
(I hope you will get my mind..I feel I have not clearly stated it ...)
Thanks
-- modified at 5:07 Friday 26th May, 2006
|
|
|
|
|
jithAtran - ii wrote: Does the compiler holds anything like a stack to store the datatype?
No, and there is no reason to. At compile time, the compiler knows that p is a pointer to int and q is a pointer to float, so when you do *p or *q, it knows how many bytes to read to get the value, so it generates code to do that. So if you write to a pointer with code like *p = 2 it generates code to write to the first four (or two, in your example) bytes of the address pointed to by p.
So yeah, at runtime, there is no information available about the pointer. The compiler cannot prevent code like this from crashing
char a = 'a';
char *pChar = &a;
void *pVoid = pChar;
int *pInt = (int *)pVoid;
*pInt = 12345; At runtime, the last line will cause problems, as 4 bytes will be written where only one byte has been allocated. The compiler cannot catch such problems, because it does not store the information anywhere.
Regards
Senthil
_____________________________
My Blog | My Articles | WinMacro
|
|
|
|
|
So i am trying to summarize my doubts.Correct me if I am wrong...
int *i;
static float *k;
int j;
i=&j;
k=&j;
printf("%d ,%f",*i,*k)
The procedure would be like this
compiler allocates 4 bytes each for pointer i and integer j. and when we prints i and k compiler reads byte information fromthe same or contigious addresses with respect to the datatype.
I still have doubt in this part.How compiler knows i is an integer.where the command "You should read only 4 bytes for i since its an integer" is stored.
of course we have declared like int *i and it stores only an address space.Will it throw error if we performed like this.
float q;
i=&q;
Thank you
-- modified at 5:34 Friday 26th May, 2006
|
|
|
|
|
jithAtran - ii wrote: I still have doubt in this part.How compiler knows i is an integer.where the command "You should read only 4 bytes for i since its an integer" is stored.
First, i is not an integer, it is a pointer to an integer. Second, the compiler does NOT store the information anywhere, it simply uses the information when it generates the machine code. When the compiler parses the program, it knows that i is of type int *, so it knows that whatever i is pointing at is an integer. Whenever it sees it being referenced/dereferenced, it uses that fact that i is a pointer to an integer to generate the correct code. To summarize, the information that i is a pointer to an integer is not stored anywhere, the compiler just generates code that treats i as a pointer to an integer.
jithAtran - ii wrote: Will it throw error if we performed like this.
float q;
i=&q;
Yes, it will. Like I said, at compile time, the compiler knows that i is a pointer to an integer, so it obviously won't allow it to point at a float.
Regards
Senthil
_____________________________
My Blog | My Articles | My Flickr | WinMacro
|
|
|
|
|
Thank you Senthil,
Now I think I am pretty clear about these concepts .Yeterday, I referred the book of computer organization by hamacher and pointers in C.Your explanations helped me to sum up the things logically.
yeah ..But ..only this
S. Senthil Kumar wrote: the compiler knows that i is a pointer to an integer
How?
Correct me if I am wrong,
Lets declare like
int *i;
compiler parses this.
That means i has been given an address space in the memory(1000/1001).
Now we are trying to store an address say
like
______________
__00__|___7D__ where 007D is the address of a
1000 1001 float variable.
Now here is my doubt.How compiler knows this assignment is wrong.Obviously,it is the alloted space for an intger.But how does compiler keeps track that 1001/1002 are for integer.
i am sorry,I think ,i have to still understand the concepts
Thank you.
|
|
|
|
|
jithAtran - ii wrote: That means i has been given an address space in the memory(1000/1001).
Now we are trying to store an address say
like
______________
__00__|___7D__ where 007D is the address of a
1000 1001 float variable.
Now here is my doubt.How compiler knows this assignment is wrong.
Well, you're not doing
int *p = 0x007D;
are you? You are attempting to assign the address of a float variable to an integer pointer, so that's why the assignment is wrong.
The compiler knows this because, when it compiles code, it keeps track of the type of all variables, using something called a symbol table[^]. When it's time to generate code, it sees this line
float k = 10.0;
int *p = &k;
it realizes that p is a pointer to int and k is a float and therefore generates an error. If you want to know how it gets that information from the source code, google for "Parsing and Syntax Analysis", which is a pretty huge topic in itself.
Again, the compiler doesn't know addresses 1001/1002 are for pointing to integers, rather, it only knows that p is a pointer to an integer. The absolute address of the pointer itself is determined at runtime.
Regards
Senthil
_____________________________
My Blog | My Articles | My Flickr | WinMacro
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
