|
This technique will work on any type of project that has the two files named. It does not have anything to do with MFC. If you don't have files by that name, put the extern in every module where you reference the global. Put the definition in any .cpp file in your project.
,
Bill
|
|
|
|
|
This technique will work on any type of project that has the two files named. It does not have anything to do with MFC. If you don't have files by that name, put the extern in every module where you reference the global. Put the definition in any .cpp file in your project.
|
|
|
|
|
If you insist on global variable (I'm leaving discussion about their value for later time), you need to do two things:
extern int g_Temp;
int g_Temp = 0;
To access g_Temp just #include appropriate header
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
For some time I'm trying to draw the caption of a dialog myself, including the buttons and the line that seperates the NC area and the Client area.
Kilowatt adviced me to add SetWindowLong to the WM_NCACTIVATE handler, but that doesn't make a visual difference. Without the SetWindowLong call the borders of the NC area aren't painted at all.
The border doesn't get painted, but that didn't happen in the first place, my problem was that not only the buttons were painted, but a small area around the buttons too, and there is a line drawn that seperates the client and the non-client area.
If I don't make a handler to NCACTIVATE at all windows paints the NC area as soon as it looses focus, otherwise not.
Maybe I didn't make myself entirely clear, but I would like windows to paint nothing at all outside of the client area, as windows refuses to draw the button without background.
Thanks in advance
|
|
|
|
|
1- _beginthreadex returns a HANDLE to the thread and the Thread ID in its last parameter. Am I right?
2- Do I have to keep the value returned by _beginthreadex in order to call CloseHandle on it, or can I safely ignore it without ending with resource leaks?
Tx
Michel
If I am wrong or said something stupid, I apologize in advance 
|
|
|
|
|
1. Yes.
2. Yes, No.
I vote pro drink ![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif)
|
|
|
|
|
Ok.. i have 2 grids in this project.. i upgraded to .NET, added a new grid to a new dialog and when i compile and run the program the 2 grids from before .NET show fine.. but the new one i added doesn't show up at all in the dialog.. i checked all of the properties of both and set them the same, but the one from .NET just doesn't want to show up.. it has visible = true..
it gives these lines in the output window when the dialog pops up:
'SCTax.exe': Loaded 'C:\WINNT\system32\clbcatq.dll', Cannot find or open a required DBG file.
'SCTax.exe': Loaded 'C:\WINNT\system32\Msflxgrd.ocx', Cannot find or open a required DBG file.
however it doesn't say anything like this whenever the older dialogs popup.. and i know that the Msflxgrd.ocx exists, because when i exit the program the output window says:
'SCTax.exe': Unloaded 'C:\WINNT\system32\Msflxgrd.ocx'
.. any suggestions anyone? this grid seems to be quite a pain to get to work in .NET.. im assuming its some sort of code that it left out when i added the control.
thanks for any suggestions
-dz
|
|
|
|
|
[you can call me naive, but] I've decided to try and build - from scratch - my own set of GDI controls. i.e., derive CWnd and do all the events and painting stuff by myself.
the main motivations for this is [a] I'd like to create specially shaped transparent controls and [b] I simply HATE those ones that MS gives.
when I tried to integrate the transparent functionality into my controls, I ran into a problem: the control should use the parent's DC to paint itself transparently. so I actually have to call my control's Draw() function (from the parent's OnDraw() function), passing it the parent's current paint DC. it seems lame to me, but sadly I didn't find any other way to do it.
I did that after I tried to intercept WM_PAINT, but it kept on calling my OnPaint() handler and it didn't give enough time for the other controls to paint their own data.....
so I investigated how MFC draws its own simple controls (CButton), and found that actually the parent's DC is being used for drawing the child control. but where? and who does the actual drawing? where in the background is that control being drawn on the screen, and re-WM_PAINT-ed everytime it should be redrawn?
I want to fully understand the simple control's display behaviour and to integrate it into my own set of controls.
any explanations, guidelines, pointers, suggestions will be very appreciated.
|
|
|
|
|
alpha+ wrote:
so I investigated how MFC draws its own simple controls (CButton), and found that actually the parent's DC is being used for drawing the child control.
I find this statement incorrect. How did you get this?
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
When you register your class for the child control, give it the class style CS_PARENTDC.
Then create an OnDraw OnPaint handler for your child control. The parent control will get the chance to paint its display first, then your child control will get its chance.
You shouldn't have to call the OnDraw handler directly, windows or MFC will take care of that for you.
|
|
|
|
|
One other thing that I forgot to mention.
In order to make a child control look transparent, you will need to handle the WM_ERASEBKGND message for you child control, and return FALSE. This will have the effect of your child control not clearing the window space below it with the default color for a window like white or whatever, and it will allow what appears on the parent control to show through for the child controls display surface.
Then when you paint the text or whatever for your child control, it will appear as though the control is transparent.
One other note, with this fix, it is no longer neccesary to use the parent windows DC. I told you in my previous post that in order to use the parent DC, set the CS_PARENTDC style for your class, this is no longer necessary.
|
|
|
|
|
You should use regions to handle transparency. They are very cool! Create an odd shaped region (CRgn) and select it (SetWindowRgn) into your device context. Windows will automatically paint only within the region. You can even have windows with holes!
See this article and this one too for instant inspiration.
/ravi
"There is always one more bug..."
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
I think that SetWindowRgn is a good way to go for irregular shaped windows and windows with holes, like you said, however, if you want the control to be transparent, but still be able to click on a that transparent portion and have your child control respond, you will need to handle the WM_ERASEBKGND message and not erase the background.
|
|
|
|
|
I'm trying to create a shortcut to a folder (rather than a file).
I've tried the IShellLink method, but it doesn't produce what I'm
after. This method requires and application to be specificed aswell.
If I specify explorer.exe, the shortcut is created with the app
c:\winnt\explorer.exe. This shortcut is on the network and is
accessed by people using NT/98 and 2k, thus it doesn't work as
explorer is in a different place!!
Does anyone know how to do a 'proper' folder shortcut?
Thanks in advance!
|
|
|
|
|
A shortcut to a folder MUST end in .lnk and a URL shortcut should end in .url
HRESULT CreateFileShortcut(
LPCSTR name,
LPCSTR workDir,
LPCSTR target,
LPCSTR args,
LPCSTR description
)
{
HRESULT hres;
IShellLink* psl;
hres = CoCreateInstance(CLSID_ShellLink, NULL,
CLSCTX_INPROC_SERVER, IID_IShellLink, (void **)&psl);
if (SUCCEEDED(hres))
{
IPersistFile* ppf;
psl->SetDescription(description);
psl->SetPath(target);
psl->SetArguments(args);
psl->SetWorkingDirectory(workDir);
psl->SetIconLocation(target,0);
hres = psl->QueryInterface(IID_IPersistFile, (void **)&ppf);
if (SUCCEEDED(hres))
{
WORD wsz[MAX_PATH];
MultiByteToWideChar(CP_ACP, 0, name, -1, wsz, MAX_PATH);
hres = ppf->Save(wsz, TRUE);
ppf->Release();
}
psl->Release();
}
return hres;
}
Todd Smith
CPUA 0x007 ... shaken not stirred
|
|
|
|
|
How can I display thumbnail for a custom image format in an explorer window?
Also, is there a simple hack to get explorer to understand other extension for a known file type when displaying a thumbnail? For example, I have these files with the extension .thm. They are really just .jpg files. How can I get explorer to see them as .jpg's?
|
|
|
|
|
Read Michael Dunn's articles on shell extensions, one of them shows how to do an icon server.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
"I'm thinking of getting married for companionship and so I have someone to cook and clean." - Martin Marvinski, 6/3/2002
|
|
|
|
|
I've read that. Unless I'm missing something, it does not deal with Thumbnails and from what I can tell, they are not just large icons.
|
|
|
|
|
Please show me a way to load and display usual image files such as jpg, gif, ... using directX technology.
Thanks a lot.
dxky
|
|
|
|
|
GDI+ is your friend - it loads and saves file types and can use directdraw surfaces.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
"I'm thinking of getting married for companionship and so I have someone to cook and clean." - Martin Marvinski, 6/3/2002
|
|
|
|
|
Hi there,
Wendsday (20 March) is new year in Iran !
I wanna say "HAPPY NEW YEAR !" to all of guys here !
and God willing, we'll can solve all problems about VC++ programming in new year !!!
I wanna thanks of:
Mr.VGirish - Panov Vitaly and etc.
and my all other friends !
With Warm Regards,
My month article: Game programming by DirectX by Lan Mader.
Please visit in: www.geocities.com/hadi_rezaie/index.html
Hadi Rezaie
|
|
|
|
|
Does anyone know of an implementation of tree/list with reordering like in Internet Explorer's favourites?
Where items can be drag/dropped to their new position with a horizontal bar showing where they will appear during the drag??
--
The Obliterator
|
|
|
|
|
I use GDI+ Graphic::DrawImage to display and print a bitmap;
for display and print preview it works fine. But when printing, the bitmap is stretched or compressed on paper, depending of the printer resolution. To correct this problem, I applied a correcting factor :
long dpiPrinter = pDC->GetDeviceCaps(LOGPIXELSX);
long dpiScreen = 96; // returned by pDC->GetDeviceCaps(LOGPIXELSX)
// when displaying
double ratio = (double)dpiPrinter/dpiScreen;
destPoints[0].X /= ratio;
destPoints[0].Y /= ratio;
...
// destPoints[0...2] are the corners of the rectangle
// delimiting the zone on which the bitmap is to be printed
graphics.DrawImage(pData->pBitmap, destPoints, 3,
0, 0, bitmap.GetWidth(), bitmap.GetHeight(),
UnitPixel);
Bitmap size is now almost correct but still a bit too large.
And I don't see any reason why I have to modify the code for
printing : MFC show the correct image in print preview, so I
assumed I would get the same result on paper.
|
|
|
|
|
You have to modify the code for the reason you said - MFC showed you how it looks on the screen, but it's up to you to match that in terms of the DPI of your printer.
Have you tried using UnitInch to draw to the printer ? Just curious, I've not tried printing in GDI+ myself but it seems like it could be promising.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
"I'm thinking of getting married for companionship and so I have someone to cook and clean." - Martin Marvinski, 6/3/2002
|
|
|
|
|
After many trials it works, and here are my conclusions, or rather my observations, because I don't have a clear understanding of what's happening.
I use the MM_LOMETRIC mapmode : logical units are 0.1 mm. The coordinates of the rectangle on which the bitmap is to be drawed are initially exprimed in these logical units. When I discovered that the size and position of the bitmap on paper were depending of the resolution of the printer, I thought of applying a correcting factor :
factor = dpiPrinter/dpiScreen
X1 /= factor
...
I get these dpi with pDC->GetDeviceCaps(LOGPIXELSX); for the printer it can be
75 ... 1200 dpi, and for screen it is 96.
On paper there was still a error of about 4 %; for example when I printed a bitmap whose
width was expected to be 50 mm, I got 48 mm on paper.
I have tested many hypotheses, including playing with Graphics.SetPageUnit(), Graphics.SetPageScale(), ... And finally an intuition, nothing rational but after all I was ready for black magic : an error of 4 %, OK let's say my dpiScreen is 100 and not 96... size and position are now perfect, for any printer resolution.
I assume that the LOMETRIC mapmode is in cause; as the logical units are not pixels, the screen resolution returned by GetDeviceCaps() is not relevant anymore; but then how do work the factor dpiPrinter/100 ? I have not tested yet with another mapmode, for example HIMETRIC (.01 mm). I guess (?) that my 100 would have to be replaced by 1000.
I can survive without understand that, but if someone has explanation...
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
