|
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.
|
|
|
|
|
http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/readme.asp[^]
Applications
The IPv6 Technology Preview for Windows 2000 contains a set of sample applications that you can use to experiment with IPv6-based traffic beyond the use of standard connection diagnostic tools such as ping6 and tracert6. The following applications are provided:
* HTTP client: The new Internet extensions dynamic link library (DLL), Wininet.dll, provides IPv6 capability so that Windows-based Internet browsers, such as Microsoft Internet Explorer, can make connections to both IPv4 and IPv6 Web servers.
* FTP client: The new File Transfer Protocol (FTP) client, Ftp.exe is capable of establishing FTP sessions with IPv4 and IPv6 FTP servers.
* Telnet client: The new Telnet client, Telnet.exe, is capable of establishing Telnet sessions with IPv4 and IPv6 Telnet servers.
* Telnet server: The new Telnet server, Tlntsvr.exe, is capable of establishing Telnet sessions with IPv4 and IPv6 Telnet clients.
========================================
http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/faq.asp[^]
What tools are required for IPv6 application development?
For Winsock IPv6 application development, you will need the following:
* January 2000 Platform SDK
* Visual C++ 6.0 or later
* Microsoft IPv6 Technology Preview
led mike
|
|
|
|
|
Hi
I have a picture box in my dialog, but I need to write something on top of it.
The problem is that the onPaint dialog method is getting called before the control repaints itself, so I can never see the text.
Someone knows what can I do to avoid this, and be able to write on top of the picture box?
Thanks in advance
|
|
|
|
|
Use picture box onPaint method instead of dialog onPaint method.
I think, it's called event, not method.
|
|
|
|
|
At the end of the dialog's OnPaint method post a custom message to the dialog. In that custom message handler paint your text.
void CMyDialog::OnPaint()
{
...
CDialog::OnPaint()
PostMessage(WM_APP + 1, 0, 0);
}
LRESULT CMyDialog::OnWmAppPlusOne(WPARAM, LPARAM)
{
ClientDC dc(this);
dc.TextOut(...);
}
Now all the usual painting is done first, then you custom message gets processed to draw the text on top of all the other controls.
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
Thanks for the quick reply people 
|
|
|
|
|
Add the WS_CLIPCHILDREN style to the dialog, so the dialog's window proc won't paint over its child controls.
|
|
|
|
|
how to access drives(including cd-drive) along with icons and display them on dialog and how to enable/disable drives permanently based on selection?
|
|
|
|
|
Like this?
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Exactly David, but how to get registered version?
The same way i m planning to do vc++?
Any guidence is appreciated.
|
|
|
|
|
Super Hornet wrote: ...how to get registered version?
Purchase it from here.
Super Hornet wrote: The same way i m planning to do vc++?
Check out the HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoDrives key. While this will indeed hide the designated drives, it does not restrict access to them. There is another registry key that you can use that will allow only administrators to use the (CD-ROM and floppy) drives.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
In a similar way as i described in reply to your question entitled:
"How to disable USB Port/Drive permanently?"
registry, registry once more registry ......
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
