|
Hi all,
I m trying to do multi threading .Actually what i want is to run multiple instances of one thread at same time. I m new to multi threading but i have done single threaded applications ...
Can anybody tell me how to do it ???
thanks in advance
Sulabh srivastava
|
|
|
|
|
Try looking at this article[^]. It's a good introduction to using threads.
Software Zen: delete this;
|
|
|
|
|
Hi guys,
I've got some code from a classmate that was developed in gcc, and which I need to compile in VC++. I know that my problem is a result of VC++ wanting me to give a constant size for an array, but frankly I don't want to  (it's not in the assignment specs). Don't worry, this isn't an integral part of the assignment, just setting it up. Here's the code that's causing the trouble:
<br />
int fixAtoi(char myAry[], int arySize){<br />
char myAry2[arySize+1];<br />
for (int i=0; i<arySize+1; i++){<br />
myAry2[i]=myAry[i];<br />
}<br />
myAry2[arySize]= '\0';<br />
return atoi(myAry2);<br />
}<br />
it's that second line there...
Like I said, I know what the problem is, but apart from pre-defining the array size, I don't know of a fix.
P.S. I hope you guys can appreciate having to read all that since I wrote it all while learning the dvorak layout (my second attempt).
Thanks guys,
Sean
|
|
|
|
|
int fixAtoi(char myAry[], int arySize)<br />
{<br />
char myAry2 = new char[arySize+1];<br />
<br />
for (int i=0; i<arySize+1; i++)<br />
myAry2[i]=myAry[i];<br />
myAry2[arySize]= '\0';<br />
<br />
int iRet = atoi(myAry2);<br />
<br />
delete [] myAry2;<br />
return iRet;<br />
}
|
|
|
|
|
You may need to change this like,
int fixAtoi(char myAry[], int arySize)
{
char *myAry2 = new char[arySize+1];
for (int i=0; i < arySize ;i++)
{
myAry2[i]=myAry[i];
}
myAry2[arySize]= '\0';
int nRet = atoi(myAry2);
delete [] myAry2;
myAry2 = NULL;
return nRet;
|
|
|
|
|
Using a variable for the size is a non-standard extension. Use new instead to allocate the array.
|
|
|
|
|
excellent, thank you very much guys. It works perfectly now!
|
|
|
|
|
Sean Wcisel wrote: I've got some code from a classmate...
Shame on your classmate for giving you bad code.
int fixAtoi(char myAry[], int arySize)
{
char myAry2[arySize + 1];
for (int i = 0; i < arySize + 1; i++)
{
myAry2[i] = myAry[i];
}
}
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Using Connect API we connecting to the smtp or pop server. Some time while connecting to the server more time to take for the response. It should possible to cancel the connnection. Any one help me.
Thanks in advance!
Have A Nice Day!
Murali.M
|
|
|
|
|
Are you referring to the sockets "connect()" API? If so, then you might try using a non-bocking
socket. If you choose to cancel then just close and destroy the socket. If the connection
succeeds then you can be notified via a Windows message or an event depending on your needs, using
WSAAsyncSelect() or WSAEventSelect().
Mark
Great job, team. Head back to base for debriefing and cocktails.
|
|
|
|
|
Could anyone tell me how to get the playtime for a mp3 music? I have
no idea of the structure of the mp3 file, I guess maybe there is a
field in the mp3 file structure which value is the playtime.
|
|
|
|
|
chocm wrote: I have
no idea of the structure of the mp3 file...
Have you tried here?
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
This is probably a dumb question, but how do you use the _MSC_VER macro?
I have created a set of macros, some of which will not work on older compilers, so I obviously need to check for this.
I'm currently making use of the __VA_ARGS__ and __FUNCTION__ macros, so if anybody could also tell me what the minimum VS version required for using these?
-- modified at 21:50 Friday 16th February, 2007
|
|
|
|
|
__VA_ARGS requires VC8 - _MSC_VER 1400
__FUNCTION__ requires VC7 - MSC_VER 1300
#if _MSC_VER >= 1300
#endif
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
Thankyou 
|
|
|
|
|
1. I create a device context with GetDC(NULL) for the screen and a bitmap with CreateCompatibleBitmap to that context, width and height specified.
The resulting BITMAP (received by GetObject) shows the correct size, but the number of color planes is 1 (although it IS a color monitor), the number of bits per color plane is 32.
Why doesn't the bitmap show bmPlanes = 3 and bmBitsPixel = 8 or 10?
2. I create a memory device context with CreateCompatibleDC(NULL) and a bitmap to it with CreateCompatibleBitmap, width and height specified.
The resulting bitmap shows a black and white context, mbPlanes = 1, bmBitsPixel = 1 (but it does show the proper size).
The online MSDN explains this:
When a memory device context is created, it initially has a 1-by-1 monochrome bitmap selected
into it. If this memory device context is used in CreateCompatibleBitmap, the bitmap that is
created is a monochrome bitmap. To create a color bitmap, use the hDC that was used to create
the memory device context, as shown in the following code:
HDC memDC = CreateCompatibleDC ( hDC );<br />
HBITMAP memBM = CreateCompatibleBitmap ( hDC, nWidth, nHeight );<br />
SelectObject ( memDC, memBM );
This produces the same result, which is IMO natural.
How can I get the correct (color) bitmap to the memory DC? (I guess if the bitmap to the device context created by GetDC were correct, that could be Select-ed into the memory context.)
3. Neither the above DDB, nor the memory bitmap points to any storage, i.e. bmBits is zero.
This is ok for the DDB, but bmBits should not be zero for a memory device context. (I want to "paint" directly in the bitmap storage.)
|
|
|
|
|
1) The format of the pixel data is not planar so planes==1. RGB data is interleaved in that case.
2) Are you sure that produces the same result when hDC is a handle to a screen DC?
*EDIT* try this
HDC hDC = ::GetDC(0);
HBITMAP hBitmap = ::CreateCompatibleBitmap(hDC, 100, 100);
BITMAP bitmap;
::GetObject((HGDIOBJ)hBitmap, sizeof(BITMAP), &bitmap);
3) I believe you need to use a DIBsection to write directly to pixel data.
Mark
-- modified at 20:12 Friday 16th February, 2007
added sample code
Great job, team. Head back to base for debriefing and cocktails.
|
|
|
|
|
1. The non-planar organization is ok on its own. I used GetDeviceCaps to query the characteristics; that too returnes 1. However, the number of colors in GetDeviceCaps is minus 1, although MSDN states, that 1 denotes more than 8 bits per pixel. Though this is not a big issue.
2. Of course if I use GetDC(NULL), then I get a DDB; that is the subject of #1 above. My problem is, that this goes against the documentation. I am doing this way in order to achieve the best performance; I don't know, if that won't be ruined by this usage of bitmap (although this appears logical to me), and I don't know, how I could verify it.
3. Using a DIB format would defeat the purpose (performance advantage with DDB). Either I don't understand something, or there is some way to work directly on the bit map.
Anyway, thanks.
|
|
|
|
|
What are you trying to do exactly?
If all your DC's have the same color depth, you don't need to worry about performance since there is no color conversion going on. If you want to manipulate the bits directly, it's better to use a DIB rather than a DDB.
|
|
|
|
|
Conversion arizes not only from different color depths. The format of the device dependent data can be different from the independent format. Example: the 24-bit color info can be kept in 32 bits.
|
|
|
|
|
1) Why do you think the planes should be anything but 1? Planar video modes are rarely used
these days.
2) I guess I didn't get the question. Your original question was "How can I get the correct
(color) bitmap to the memory DC?". What, to you, is "the correct (color) bitmap"?
3) Using a DIBSection gives you all the performance of a DDB plus direct access to the bits.
That's what they are for. You don't get access to the bits with a DDB. That field in the BITMAP
struct is for use by other APIs, including some related to DIBsections.
Great job, team. Head back to base for debriefing and cocktails.
|
|
|
|
|
1. A rather polemic question, isn't it?
2. Of course "correct color" is something more than one bit per pixel (i.e. not what I received in CreateCompatibleBitmap).
3. Yes, that's what my comparisons resulted.
Thanks
|
|
|
|
|
Vancouver wrote: 1. A rather polemic question, isn't it?
Wasn't meant to be. Using GetDeviceCaps(NUMCOLORS) is useful for getting a color table size and
that's about it. The BITSPIXEL and PLANES items are the most useful for creating a DDB/DIB with
a format which matches a device. The NUMCOLORS item is helpful when you need to create a palette
and/or a color table.
Vancouver wrote: 2. Of course "correct color" is something more than one bit per pixel (i.e. not what I received in CreateCompatibleBitmap).
"Of course" to you, but to us non-mind readers it's not so obvious. In my original response I
posted code that does NOT return a bitmap with a monochrome format (unless you have your video
set to a monochrome mode). You stated something doesn't match the documentation, yet I am unable
to find what you were referring to specifically. This stuff hasn't changed since the beginning
of Windows so the documentation is pretty mature, so, I respectfully disagree .
Vancouver wrote: 3. Yes, that's what my comparisons resulted.
Since my original response you have found a solution so I guess that makes the above points
irrelevant anyway. I just won't be able to sleep at night if you go on thinking that you can't
create a DDB the same format as the screen...after all, you may need to do that someday - for
double buffering and the like.
Cheers!
Mark
Great job, team. Head back to base for debriefing and cocktails.
|
|
|
|
|
I found following, which might be useful for others, who don't have experience with GDI yet (like myself):
1. SetPixel works directly on the DDB, as well as on a memory DC (the latter has to be copied by BitBlt over the DDB). The performance is the same both ways, but via the memory DC it is flicker-free. On the other hand, when building a large image, the smooth construction of the image too can be an advantage.
However, SetPixel is terribly slow, it is suitable only for a small segment.
2. SetBitmapBits allows for working "quasy" on the buffer, i.e. working on an own device dependent buffer and copying it over the device context's buffer. This is very fast.
Interesting is, that it does work directly with the DDB; not only, that it does not report any error, but one can retrieve the same values with a subsequent GetBitmapBits.
HOWEVER, the content will not be displayed.
Doing the same on the memory context and copying that over the DDB works fine.
Unfortunately, this way three buffers are involved. This is not a small issue: each of them can be many megabytes large, and for the complete construction of the image, all three have to be processed in terms of reading and writing. It is not an ideal solution.
3. I got the very best (i.e. fastest) result by using a DDB without connected bitmap, and a DIB section, working directly on the bit map and BitBlt-ing it over the DDB.
|
|
|
|
|
I have to send a file over SFTP. Besides those SFTP third party solutions that are available, like WS_FTP etc.. Does MFC have some way of coding for SFTP. I can do regular FTP through MFC.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
