|
well ...scaling must be done with a "scaling factor" meaning...
double scale=1;
CreatFont.withsize(12*scale) //... that will equal to 100% scaling...
scale=2;
CreatFont.withsize(12*scale) //... that will equal to 200% scaling...
scale=3;
CreatFont.withsize(12*scale) //... that will equal to 300% scaling...
everything must be done the same way ... (by a scaling factor)
bitmap scaling must be done with a generic algorithm (StrechBlt is only good in winXP)
or use GDI+
|
|
|
|
|
Hi,
Iam trying to read a file and i want to put it in buffer. Do i have to use read and write ? Are this stuff the only way or can i use filebuf? I read about this class but i dont understand at all if i can use it
Thanks
Youpie
|
|
|
|
|
Sorry i forgot to say i was trying to open a binary file and send the buffers thoughout a socket.
Thanks
Youpie
|
|
|
|
|
Mije wrote:
Do i have to use read and write ?
Are you talking about in the general sense, or are you talking about istream::read() and ostream::write() ? If the former, yes. If the latter, no.
Mije wrote:
...can i use filebuf?
filebuf::open() can be used to open a file for I/O.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
Hello,
I have an application where I start UI threads from time to time. The UI threads have member vars that they never change they only read..
Before I resume/start a thread I create a pointer to the thread in my main application and store the pointer in a vector. At times I need to change a threads member variable but I first need to make sure that the pointer to the thread is still valid. I'm not sure if this is the right way to do it.
if(pThread != NULL)
{ } // Change the var
Even though I check to see if the pointer is valid every now and then it crashes saying that the memory was already freed when I try to change the var.
Is this safe?
Is the if(pThread != NULL) safe? or is there a better way?
Any ideas on how I can be sure the thread is still there and will not exit while I access this member var?
Thanks,
Rob
Whoever said nothing's impossible never tried slamming a revolving door!
|
|
|
|
|
No and No
1. You need some kind of locking strategy to sync the main thread and the UI threads or bad things will happen (Oh, it already does )
2. The threadhandle in the main thread doesn't "know" that a thread has exited. You need to check this. There is a sys call to get the exitstatus of the thread, it will tell you if it is still alive. There are other ways to do this aswell.
Good luck!
|
|
|
|
|
You need some kind of locking strategy to sync the main thread and the UI threads or bad things will happen
I dont think locking is required, since the UI thread is not modifying the variables.
To check whether the thread has exited or not, use GetExitCodeThread API.
"A robust program is resistant to errors -- it either works correctly, or it does not work at all; whereas a fault tolerant program must actually recover from errors."
|
|
|
|
|
If you think that accessing (reading) a variable is an atomic operation, be my guest and go ahead. Ok, some types MAY be accessed atomically but the point is: If you are asking those questions, you don't know.
|
|
|
|
|
my dear friend,
I am not the one who raised the hands. I was just giving a comment on your point!!!
"A robust program is resistant to errors -- it either works correctly, or it does not work at all; whereas a fault tolerant program must actually recover from errors."
|
|
|
|
|
I noticed that after I submitted my reply. *DOH*
Since he was talking about variables in general terms I felt that I really should stress the point that a reader/writer releationship "always" need syncronization. Those errors are hell to find otherwise.
|
|
|
|
|
Stefan Pedersen wrote:
...a reader/writer releationship "always" need syncronization.
Agreed.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
Thanks for the input..
Rob
Whoever said nothing's impossible never tried slamming a revolving door!
|
|
|
|
|
This is my OpenGL window OnPaint function:
void COGLWnd::OnPaint()
{
CPaintDC dc(this);
HDC hdc = ::GetDC(m_hWnd);
if (!SetGLContext(hdc))
return;
RenderScene();
SwapBuffers(hdc);
::ReleaseDC(m_hWnd, hdc) ;
}
1. Do I need to release the hdc at the end of the function?
2. And would using the 'dc.m_hDC' of the CPaintDC class as the device context instead
of the retrieved from ::GetHDC(m_hWmd) make any difference. Are they both the same
thing?
|
|
|
|
|
1. Yes
2. If I remember correctly (haven't done painting stuff for a while) the CPaintDC class prepares the window dc for painting (calling BeginPaint on creation and calls EndPaint when destroyed).
So, I guess you should skip the GetDC and ReleaseDC calls alltogether and only use the CPaintDC (which, if I remember correctly has a HDC operator).
|
|
|
|
|
I want a powerOff off ATX's tower after the shutdown(Win2000 and 98), without the user's interation. Thanks for Any help...
Wanft
|
|
|
|
|
I think in most cases if the shutdown does not power off than windows does not know how to power off the system. There are problems with different power standards with older bioses. There is a shutdown after power off registry setting but in most cases it is set correctly.
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\PowerdownAfterShutdown
John
|
|
|
|
|
thanks!
|
|
|
|
|
Is it possible? I am designing a thread pool and I have a vector of thread handles. If I need to terminate a thread I need to inform the derived class that the thread was terminated for this I need to send the thread ID. I know I could just store the thread id as a class member variable also but can I get a thread id of an executing thread knowing its handle??
John
|
|
|
|
|
Use GetThreadId( ) API
DWORD GetThreadId(
HANDLE Thread
);
It should work in Win2k.
"A robust program is resistant to errors -- it either works correctly, or it does not work at all; whereas a fault tolerant program must actually recover from errors."
|
|
|
|
|
I have just been told on another site that that only works for Windows 2003 and and above...
John
|
|
|
|
|
Its actually implemented in kernel32.lib. So it should work.
"A robust program is resistant to errors -- it either works correctly, or it does not work at all; whereas a fault tolerant program must actually recover from errors."
|
|
|
|
|
Thanks for the info..
John
|
|
|
|
|
I'm using VisualC++ 6.0. How can create a project so I can use and return CString?
Cheers,
Jo
|
|
|
|
|
Umm I'm assuming that this isn't the question you actually meant, but all you have to do is create a MFC Dll in the wizard and you have access to it.
Mike
|
|
|
|
|
Mike Danberg wrote:
I'm assuming that this isn't the question you actually meant
Actually, that is the question I was asking. I'm very new to DLL, so when I started, I just created Win32DLL (there is no option to enable MFC on this Win32DLL project type in VC++6.0 AppWizard), then later I found out I need to use CString. So in that Win32DLL, I added #include <afx.h> after #include <windows.h> (this .h is included by the AppWizard). As it turns out in Afx.h there is macro that said you can't include #windows.h if you want to use Afx.h
So that is the reason I have that Q. Now I know I have to choose MFC(DLL) project type. Thanx.
cheers,
Jo
|
|
|
|