I'm pretty sure this will write the characters to file in ASCII, won't it? I was trying to write it as binary. The thing is, I'm trying to do a minimalist database design, so writing out the x and y ordinates of 13945 and 19053 as ASCII would take 10 bytes, whereas as a 32-bit int, would only take 8 bytes.
The software I am coding uses AfxThrowArchiveException(CArchive::none) to undo changes made by partially loading a document into the program. However, another afx message stating "Failed to open document." pops up and the operator has to again click OK on the dialog. Is there anyway to override this second message box from popping up?
I know there are numerous articles on this topic, but I haven't found a solution to my problem.
From my GUI app I launch a stub process which is supposed to give me real time feedback on the output of a third console. Basically I set up the pipes and handles from the GUI, launch the stub which inturn modifies it's screen buffer and launches the real console. All the handles are inherited correctly, until I modify the memory of the real console.
I coded the stub to start the new process with the CREATE_SUSPENDED flag set, it also returns the ID's back to the GUI. From there I modify the memory and call ResumeThread(). But, for some reason, the STD_OUTPUT_HANDLE which it should have inherited from the stub has been lost. I have verified that the real console is indeed running, though it has no 'visible' screen buffer to output it's contents to.
Through inheritance, I do get the screen contents, but not in real time and without any of the modifications that the stub was supposed to perform.
Any ideas as to how or why this might have happened? Is there any way I can reset the std_output handle after a call to CreateProcess() ?
I've made the change and the background bitmap doesn't flicker at all, however, the controls ontop of the bitmap still flicker.
This is the change I've made:
KeyHandler now triggers OnEraseBkgnd instead of performing PatBlt
When the user presses a key, the key's number is stored in a private member variable of the Dialog.
To subsequently make it update the background image, the Dialogs' key handler performs :
OnEraseBkgnd now does the PatBlt of the static image behind the controls
Next, OnEraseBkgnd(CDC* pDC) is processed.
this handler first checks that a key was pressed, if so, it performs the targetDC.PatBlt (I just use the pDC that's passed in) then it returns TRUE.
If no key was pressed then I let this handler perform the default CDialog::OnEraseBkgnd(pDC)
After this change I noticed that the individual controls no longer need their RedrawWindow() called, however, they still flicker (but the background static image doesn't flicker at all now).
I've also removed the SetRedraw() calls
No the properties won't change, but I'm calling quite a lot of RedrawWindow methods for the controls on the Dialog and I'm noticing that the bigger the controls, and the more there are, the more flicker I'm seeing.
Last Visit: 31-Dec-99 18:00 Last Update: 9-May-21 23:26