|
Hi,
I want to know the width of a font,Before I Create a font. My aim is to provide
a character ratio for the font.
Iam creating the font using the "CreateFont" method.In this Function,the 2nd parameter
is width.So to Create a Font with a particular character ratio,I need to give in this 2nd
parameter a value which is equal to (widthoffont * characterratio).
sO THATS why I want to know the width of the font before creating a font before.Is it
possible?.
I tried as u told:
CFont font:
LOGFONT lf;
memset(&lf, 0, sizeof(LOGFONT));
font.CreateFont(-height,0,rotVal.x ,rotVal.y,style,FALSE,FALSE,0,ANSI_CHARSET,
OUT_DEFAULT_PRECIS,CLIP_DEFAULT_PRECIS,DEFAULT_QUALITY,DEFAULT_PITCH|FF_SWISS,
reinterpret_cast(facename.c_str()));
// In "CreateFont" method Iam giving width as 0 in the 2nd parameter as I dont know the width in advance & I tried to get the width windows allocated using the logFont Structure. But Iam not getting the width windows allocated instead Iam getting '0' which I gave in the "CreateFont" method.How is it possible to get the width windows allocated.
Would be nice if someone tells me how to achieve this....
font.GetLogFont(&lf);
long width = lf.lfWidth;
font.CreateFontIndirect(&lf);
Thanks in advance.........
|
|
|
|
|
i need to boot from flash. OS can be win98 or linux.
how can i do that
|
|
|
|
|
Call me a sceptic, but USB technology is still kept in the dark due to very large $$$ potential to private companies.
|
|
|
|
|
Set your BIOS to use the USB as a boot device and have your flash-stick formatted as a bootable device.
Now it SHOULD work....
If it does, you have the reassuring knowledge that you are far ahead of the common mob. 
In other words, it seems to be plain luck.
Newer computers and notebooks tend to do better with USB than older desktops.
Who is 'General Failure'? And why is he reading my harddisk?!?
|
|
|
|
|
Hi All
does ne1 know how to add an HTML help to a sdi appplication genertated in Visual Studio 2003
normally this would be created at the start of the project, but i didnt think that i would require
one, however i now need to add one to my project
does anyone know how to do this
thanks
simon
|
|
|
|
|
Hi
Now I develop a control derrived from static text.
In PreSubclassWindow() I need to call GetFont(). If control is created via dialog editor everything is OK, but when I try to create it in OnInitDialog() handler using Create() method, GetFont() returns NULL.
Why is it so.
____________________
Best regards,
v0id
|
|
|
|
|
Just a stab in the dark, but I think if your call GetFont() before CDialog::OnInitDialog(), the dialog as not been initialised/created, therefore will bomb out.
Try it after the base function is called and see what happens
I Dream of Absolute Zero
|
|
|
|
|
This is a guess, but by the end of the stadnard OnInitDialog, wit hte controls created, the CDialog bass class code calls setFont on each control to set the font to use.
As your doing the Create() calls manually, not font is being set. he control will render with the default GUI font (GetStockObject(DEFAULT_GUI_FONT)), but will return NULL as no specific font to use has been set.
Roger Allen - Sonork 100.10016
If your dead and reading this, then you have no life!
|
|
|
|
|
hi all,
i want to write a program that alows videochating,i do not know how to capture image from webcam, and how to compress it. Can any one help me?
thanks.
|
|
|
|
|
Get the DirectX SDK and look thru some of the samples. http://www.microsoft.com/windows/directx/default.aspx
|
|
|
|
|
How can I delete files from my Visual C++ program?
Christian
|
|
|
|
|
int remove( const char *path );
|
|
|
|
|
|
Press Del in the Project window file list.
Neville Franks, Author of ED for Windows. Free Trial at www.getsoft.com
|
|
|
|
|
Neville Franks wrote:
Press Del in the Project window file list.
hahahaha
The World is getting smaller and so are the people.
|
|
|
|
|
Would you please tell me how to store, retrieve and display .bmp file using sql server 2000 and vc++ 6.0?
Thanks a lot!!!
|
|
|
|
|
I'm encountering a strange problem in multithreaded code (I can hear the groans now  ). In a nutshell, my app is MDI where each document has a CListView attached. Each CListView spawns two threads. The first thread monitors a file and, when the file changes, reads the changes and adds the change records to a list. The second thread is signalled by the first thread when the list changes and updates the ListView with the new data.
As part of the shutdown sequence for the program I signal a stop event monitored by each thread which, when signalled, causes the thread to terminate. The stop event is manual reset. Then I wait upon each thread handle to be sure the thread has in fact terminated. Because the work in each thread is inside a loop not directly controlled by the WaitForXObject(s) call there's another boolean variable used to signal the thread, at each iteration of the loop, if I want it to return to the WaitForXObject(s) call. The thread that sets that variable sleeps for a couple of timeslices to be sure the threads see the change. (It makes no difference in the outcome if the thread that sets the variable sleeps 10 ms or 10 seconds).
It all works perfectly if I let it run to completion, ie
file changes
monitor thread notices changes and creates change records, adds them to list
update thread is signalled and copies new records into the view
but if I try to exit the app while the update thread is still processing change records the app hangs about half the time in a call to CListCtrl::InsertItem. I can let it sit there for an hour and nothing happens (and 0% CPU for the app). Breaking under the debugger when it's hung reveals the update thread is waiting for CListCtrl::InsertItem to return.
The thread procedure gets the this pointer to the CListView as the LPVOID parameter. Examining the code for CListCtrl::InsertItem reveals it's a simple wrapper around a ::SendMessage call using the HWND of the CListCtrl embedded in the view (ie, not using the MFC temporary CWnd mechanism. This explains why it works most of the time (no cross thread problems with CWnd's)).
When I break using the debugger during the hang I can see that the CListView is still valid and the embedded CListCtrl is also still valid (both have valid HWND's which Spy++ can see). So I can't imagine why it's hanging in the InsertItem call. Since the InsertItem call uses ::SendMessage rather than ::PostMessage it's not message pump related.
Any ideas? Any experience with hangs in CListCtrl::InsertItem?
Rob Manderson
http://www.mindprobes.net
"I killed him dead cuz he was stepping on my turf, cutting me out of my bling the same way my ho cuts cookies, officer"
"Alright then, move along" - Ian Darling, The Lounge, Oct 10 2003
|
|
|
|
|
Rob Manderson wrote:
Since the InsertItem call uses ::SendMessage rather than ::PostMessage it's not message pump related.
Are you sure? SendMessage waits for the window procedure to complete, if you no longer have a GUI thread it isn't going to be processed.
You could ensure your update threads exit before your main application thread, or use PostMessage instead. I think I would go for the first option.
Ryan.
|
|
|
|
|
SendMessage does a direct call to the WinProc whereas PostMessage adds a message to the message queue and waits for normal message pumping.
The main application thread is still running when the stop event is signalled.
Rob Manderson
http://www.mindprobes.net
"I killed him dead cuz he was stepping on my turf, cutting me out of my bling the same way my ho cuts cookies, officer"
"Alright then, move along" - Ian Darling, The Lounge, Oct 10 2003
|
|
|
|
|
I think you've deadlocked.
According to your description, you set the event object to signal that the update thread should shut down, then wait for the update thread to quit. While waiting, the UI thread is blocked.
I assume that the update thread looks something like:
while ( WAIT_TIMEOUT == WaitForSingleObject( hUpdateQuitEvent, 0 ) )
{
m_pList->InsertItem( );
}If the UI thread runs at point A, sets the event and then waits on the thread handle before the update thread continues to the next line, the UI thread is blocked while the update thread calls SendMessage.
SendMessage does indeed do a direct call, if and only if the thread calling SendMessage is the same one that created the window. Otherwise, SendMessage adds a message to the window's thread's message queue (which takes priority over posted messages) and blocks until either the windows procedure returns or until it calls ReplyMessage. The sent message is processed the next time a message is retrieved by the window's thread (within GetMessage - a sent message does not cause this APIs to return).
I recommend getting rid of your update thread completely, as it appears to be an unnecessary complication, and posting a custom message in the WM_USER range (with PostMessage) to your UI thread from the monitor thread, where you would have signalled your update thread. That message will then be processed next time your UI thread is idle. You should then be able to shut down the monitor thread with impunity.
|
|
|
|
|
Mike Dimmick wrote:
SendMessage does indeed do a direct call, if and only if the thread calling SendMessage is the same one that created the window. Otherwise, SendMessage adds a message to the window's thread's message queue (which takes priority over posted messages) and blocks until either the windows procedure returns or until it calls ReplyMessage.
Ah ha!!! I didn't know that
In the light of your comment (and the other replies to my question) I'm rethinking the strategy to eliminate the UpdateThread. Alas performance suffers a little but I'll live with that in return for increased robustness.
Rob Manderson
http://www.mindprobes.net
"I killed him dead cuz he was stepping on my turf, cutting me out of my bling the same way my ho cuts cookies, officer"
"Alright then, move along" - Ian Darling, The Lounge, Oct 10 2003
|
|
|
|
|
Rob Manderson wrote:
Ah ha!!! I didn't know that
In that case, I recommend chapter 26 (Window Messaging) of Jeffrey Richter's Programming Applications for Windows, Fourth Edition. Heck, I recommend the whole book. 
Chapter 26 goes into great detail about what's available with window messages, how they're processed, and how you can process them. I use window messages for a large part of my interthread synchronisation and communication.
This book should very much be considered the counterpart to Petzold's Programming Windows - Petzold teaches UI, controls and graphics, while Richter teaches threads, processes, jobs, memory, synchronisation, scheduling, DLLs, exception handling, window messages and input.
|
|
|
|
|
If I've read this correctly you are (indirectly) calling SendMessage() from a worker thread to act on a window that lives in the main app thread. If so you are asking for trouble, because it is very easy to get into a deadlock situation. This can happen because the main thread is processing some windows request, and your sendmessage has to wait until tht finishes and these actions beat on each other. It is late here on Oz and this isn't sounding too good. 
To do this sort of thing across threads I always use PostMessage(). If the worker thread has to wait until the message has been processed then I use an event which I wait on in the worker thread. The app thread will signal the event when it has done whatever I've requested of it.
Another approach for this specific bit of code might be a publish-subscribe approach, where the worker threads publishes the information to say an STL vector, and the app thread checks this from time to time and pulls stuff which is waiting. But I'm probably heading off the track and off to bed.
Hope I've been of help.
Neville Franks, Author of ED for Windows. Free Trial at www.getsoft.com
|
|
|
|
|
Yup, you and Mike have both been of help, if only to convince me to drop the two thread approach and use the PostMessage mechanism instead 
Rob Manderson
http://www.mindprobes.net
"I killed him dead cuz he was stepping on my turf, cutting me out of my bling the same way my ho cuts cookies, officer"
"Alright then, move along" - Ian Darling, The Lounge, Oct 10 2003
|
|
|
|
|
Threads have their place, and are especially usefull when there are some serious background processing requirements. In ED (see sig) I use threads for Find/Repalce in Files, Source Database updates etc. and they make for a much better user experience. However getting your design and implementation 100% correct so you can't get into a deadlock situation can be quite difficult. And of course there may also be synchronization issues. MFC makes multithreading which interacts with GUI components more difficult because CWnd maps aren't accessible across threads.
I wouldn't give up on your multithreading, but maybe it can be simplified down to a single thread. And make sure you never call anything that calls any function that can block, like SendMessage().
As an aside I use a technique similar to what you describe to end threads, however the technique that Peter Hancock uses in "An exception safe OO thread-pool framework" is quite neat. See: http://www.codeproject.com/threads/threadlibrary.asp[^] Peter forces the thread to throw an exception and then shut itself down (or something like that). Worth a look. Also the thread pool itself is very good.
Neville Franks, Author of ED for Windows. Free Trial at www.getsoft.com
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
