|
toxcct wrote:
you don't even post to the right person...
Cool Down TOX!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
|
|
|
|
|
whoops...sorry about that...
thats what happens when u try to make a lightning fast reply...
"Some guys hack just to get themselves a girlfriend.What a pathetic reason huh ?"
|
|
|
|
|
lol, nevermind, i didn't take it for me 
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
|
 hi all
how can i render a text with halo effect using win32 GDI functions
need help urgent!!!
regards
pradish
|
|
|
|
|
What do you mean by the 'halo effect' exactly?
You might look at DrawFocusRect for guidance on the common 'dotted rectangle' surrounding selected items.
The DrawFocusRect function draws a rectangle in the style used to indicate that the rectangle has the focus.
|
|
|
|
|
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?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
