|
I presume you are talking about something similar to the blue "glow" that you get on OS X edit fields?
One thing you could do is to customize the WM_NCPAINT message. This allows you to paint in the "border" region, i.e. the non client area, of a control. You could customize the size of the non client area and then with WM_NCPAINT you could draw you own glow effect, however you choose to do that.
If you want to actually render the *text* with a halo, win32 GDI has no functions that do this. You might look into GDI++, or some other alternate library like AGG[^] to help out with that.
¡El diablo está en mis pantalones! ¡Mire, mire!
Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!
SELECT * FROM User WHERE Clue > 0
0 rows returned
Save an Orange - Use the VCF!
|
|
|
|
|
I have seen various people using various macros for the same purpose, and that confuses some people
Should I use _T or TEXT?
Should I use _TCHAR or TCHAR?
Jeffrey Richter uses TEXT and TCHAR in his book, but at all other places I have seen _T and _TCHAR.
|
|
|
|
|
_T() allow you to be unicode/ansii independant...
so, if you just - one day - #define _UNICODE, if you use the _T() macro, you won't have to change anything in your code, and it will support unicode.
of course, if you do so, use TCHAR instead of char...
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
Flace wrote:
Should I use _T or TEXT?
Should I use _TCHAR or TCHAR?
It's upto you what to use, as they are same, i.e. nothing difference between them
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
|
|
|
|
|
I have this piece of code:
<br />
result = RegOpenKeyEx(hkey, registrykey, 0,KEY_SET_VALUE ,&key);<br />
where registrykey is a _TCHAR *. This line compiles fine with _MBCS defined, but when I change it to _UNICODE, I get this error:
error C2664: 'RegOpenKeyExA' : cannot convert parameter 2 from 'unsigned short [512]' to 'const char *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
Any idea why 'RegOpenKeyEx' is getting resolved to 'RegOpenKeyExA' when _UNICODE is defined? Can we fix this problem without explicit casting? Thanks in advance.
|
|
|
|
|
Where did you define _UNICODE? It needs to be defined for all the files (at the project level, for example)
Or maybe you didn't re-create your pre-compiled headers?
'RegOpenKeyEx' getting resolved to 'RegOpenKeyExA' means _UNICODE wasn't defined at the time the compiler found its declaration.
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
Jose Lamas Rios wrote:
Where did you define _UNICODE? It needs to be defined for all the files (at the project level, for example)
Yeah, I defined it in the project settings. I just changed _MBCS to _UNICODE.
Jose Lamas Rios wrote:
Or maybe you didn't re-create your pre-compiled headers?
I changed 'Automatic use of precompiled headers' to 'dont use precompiled headers', and got the same errors.
Jose Lamas Rios wrote:
'RegOpenKeyEx' getting resolved to 'RegOpenKeyExA' means _UNICODE wasn't defined at the time the compiler found its declaration.
Note that _TCHAR is getting resolved to unsigned short, I am wondering whats going wrong with RegOpenKeyEx...
|
|
|
|
|
Flace wrote:
Note that _TCHAR is getting resolved to unsigned short, I am wondering whats going wrong with RegOpenKeyEx...
Try defining UNICODE (with no leading underscore) too. It seems like _UNICODE affects MFC headers, while UNICODE affects Win32 API headers.
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
Jose Lamas Rios wrote:
Try defining UNICODE (with no leading underscore too). It seems like _UNICODE affects MFC headers, while UNICODE affects Win32 API headers
Right, I just noticed that that RegOpenKeyEx resolves to RegOpenKeyExW when UNICODE is defined, and not when _UNICODE is defined. I couldnt locate if UNICODE is automatically defined when _UNICODE is defined. So I now changed _UNICODE to UNICODE in the project settings, now tchar.h doesnt seem to know about UNICODE:
error C2664: 'RegOpenKeyExW' : cannot convert parameter 2 from 'char [512]' to 'const unsigned short *'
|
|
|
|
|
Ok, the problem goes away if I define both UNICODE as well as _UNICODE.
Is this how it is supposed to be?
|
|
|
|
|
Flace wrote:
Ok, the problem goes away if I define both UNICODE as well as _UNICODE.
Is this how it is supposed to be?
It does seem so
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
Get rid of the _MBCS and define both UNICODE and _UNICODE.
#include <windows.h>
#include <tchar.h>
const TCHAR *mykeyname = "Software\MyCompany";
Then call RegOpenKeyEx...
|
|
|
|
|
Oops this should read...
static const TCHAR *mykeyname = "Software\\MyCompany";
|
|
|
|
|
Anonymous wrote:
static const TCHAR *mykeyname = "Software\\MyCompany";
Small Question, Why are you using static with const or vice versa 
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
|
|
|
|
|
Crap everything, he forgot the _T macro. Also, you don't need the static. Correctly, it should read:
const TCHAR *mykeyname = _T("Software\\MyCompany");
|
|
|
|
|
One Stone wrote:
Correctly, it should read:
Actually My Question is:- if he want to make any thing static then why he making it const or vice versa.as after making const we cannot change it value, so no use of static.
Secondly :-
One Stone wrote:
const TCHAR *mykeyname = _T("Software\\MyCompany");
const TCHAR *mykeyname = "Software\\MyCompany";
This will compile too, but that wouldnot be right approach .
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
|
|
|
|
|
After diving a lot in MS and other web waters, I must draw the following conclusion:
many ambiguities are kept alive about GDI, GDI+, DIB, DDB, ... and the GDI/GDI+ doc doesn't help much.
One of the best article I read about GDI+ is from Borland! ( http://bcbjournal.org/free_issue/vol8_num6.4.htm )
There are some abiguities I'd like to clear, please read the questions carefully and reply only if you know the answers for sure, thank you.
1. GDI+ Bitmap class loads a file
- is the bitmap generated for sure a DIB? (ie not a DDB)
will the bitmap have the same PixelFormat as the one inside the file for sure?
(should be the case, but read so many various things on the web...)
2. GDI+ Bitmap class and palettes
When a GDI+ Bitmap is read from a file in which a palette is embedded (e.g. a GIF) the superclass Image provides a GetPalette method, while the subclass Bitmap does not. So, what happens after a Bitmap::LockBits where the requested PixelFormat is Indexed?
- Does LockBits provides a color table (palette) somewhere? How to get it?
3. GDI+ to HBITMAP etc...
After reading an image from a file, assuming the file format of Image is the one of the file, the corresponding old HBITMAP handle is necessary:
- will Bitmap::GetHBITMAP provide a "safe" handle (ie the Image object can be deleted?)
What about the Palette, if any:
- is a HPALETTE handle available somewhere, or the Image::GetPalette() call is necessary (after GetHBITMAP) and the re-construction of a HPALETTE object/handle is mandatory?
Thanks again
Regards
|
|
|
|
|
EastMohican wrote:
is the bitmap generated for sure a DIB?
Yes, it always has the same pixel format as the image on disk
EastMohican wrote:
Does LockBits provides a color table (palette) somewhere? How to get it?
Lock bits provides the bits only, and may actually throw an exception if the image is 8 bit.
EastMohican wrote:
will Bitmap::GetHBITMAP provide a "safe" handle (ie the Image object can be deleted?)
I doubt it. An Image has to be a HBITMAP, no matter which way you look at it. So the easiest thing, and the least memory intensive thing, would be to pass the handle of what I assume is internally a DIBSection.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Thanks a lot Christian.
Maybe a last question about palettes:
after getting the HBITMAP from my GDI+ Bitmap::GetHBITMAP() method, in case the bitmaps is (for instance) Indexed 8 bits, where can I get the accompanying Palette information (if any) in order to make a HPALETTE (GDI)object?
|
|
|
|
|
I'm sorry, I skipped that one as I have no idea. I only know about the exception thrown because people who have used my image processing code have reported it. I tried to stop my code loading GIF ( there was some talk that using GDI+ to load gif means that the third party needs to pay a Unisys licence, even if the code is free ), and I never use palettised images.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
EastMohican wrote:
after getting the HBITMAP from my GDI+ Bitmap::GetHBITMAP() method, in case the bitmaps is (for instance) Indexed 8 bits, where can I get the accompanying Palette information (if any) in order to make a HPALETTE (GDI)object?
I think that, assuming the HBITMAP is a DIB, then calling GetDIBits and using DIB_PAL_COLORS will cause the BITMAPINFO's bmiColors array to be filled with the palette values.
¡El diablo está en mis pantalones! ¡Mire, mire!
Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!
SELECT * FROM User WHERE Clue > 0
0 rows returned
Save an Orange - Use the VCF!
|
|
|
|
|
Hi Jim,
thanks for your contribution.
Actually GetDIBits will take the bitmap handle and process the data in order to provide the requested format. E.g. DIB_PAL_COLORS for indexed colors, or DIB_RGB_COLORS for straight colors...
However, I don't need another processing! But rather retrieve the Palette information after GDI+ Bitmap::GetHBITMAP has been called... if the initial bitmap (handled HBITMAP) was actually Indexed, there should be the information somewhere in the Bitmap object!
regards
|
|
|
|
|
Christian Graus wrote:
EastMohican wrote:
is the bitmap generated for sure a DIB?
Yes, it always has the same pixel format as the image on disk
Yes, but I was a little bit confused working with grayscale JPEGs. Working with such images using libjpeg, for example, you can determine that the image is grayscale. But GDI+ is loading such images using Format8bppIndexed.  So, how to check that the image is grayscale ? Only analyzing it's palette. 
Christian Graus wrote:
Lock bits provides the bits only, and may actually throw an exception if the image is 8 bit.
Yes, it may. But why not to lock using the pixel format of the image ? So, you will not get exceptions. Besides, you will not get exception if you are locking for read only. It works for 8 bit images locking them as 24 bit.
Andrew
|
|
|
|
|
Thanks Andrew. Any idea about the Palette if I want to convert a GIF to HBITMAP for instance (without forcing the pix format as > 8 bits) ?
<< after getting the HBITMAP from my GDI+ Bitmap::GetHBITMAP() method, in case the bitmaps is (for instance) Indexed 8 bits, where can I get the accompanying Palette information (if any) in order to make a HPALETTE (GDI)object? >>
|
|
|
|
|
Sorry, but I have no ideas. I remember, that I had some problems with palette of HBITMAP. But it was not so important for me that time. I am working mostly with image processing, so it's not preferable for me to work with 8 bpp images (only if they are grayscale).
Andrew
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
