|
Hi, thanks again for your reply, I'm grateful for your suggestions.
You are of course right, but the problem is that some of the (less responsible) users I am writing this program for *are* likely to reboot mid-program - with the intention of accessing the temporary files. I'm actually writing a freeware 3rd party packer and launcher for a "hobbyist" game engine. Because it is third party, it needs temporarily to write a few of the game files to disk (nothing can be done about that, short of writing a whole virtual file system which is way beyond my ability). The main concern of some of the users who will use this program to pack and launch their own games will be how safe their temporary files are (as these temporary files may be original models or even game scripts that have taken a lot of work). To facilitate this I have added about as much protection as is reasonable for files that have to be temporarily on the hard drive - the files are deleted if the program is exited or if the system is rebooted, and whilst the game is in action the user can be prevented from alt-tabbing to Windows to find the files (the last part is optional - most people, myself included, would not want to use a program that prevents the switching to Windows whilst in use, but I've included the option for those developers who want to release demos to other users of the engine whilst the game is in development, so that they can prevent others ripping their files).
So essentially, it's a security issue as opposed to a "cleanliness" issue, which is why I want to include the remove-on-reboot code but also cancel it if it proves unnecessary. I hope this makes sense. I'm aware that what I want to do isn't ideal, but it's kind of necessary.
Again, many thanks, and any further help that anyone can give would be much appreciated.
Cheers,
KB
|
|
|
|
|
Why not use memory files. I don't know if you are using MFC, but have a look at the CMemFile class. I would think other class libraies would have something similiar.
Sonork 100.11743 Chicken Little
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
Within you lies the power for good - Use it!
|
|
|
|
|
Many thanks for your reply. Frankly, I would love to use memory files and avoid writing the data to disk at all. Unfortunately, I don't think it's practical - I wish it was. The problem is this:
My app is essentially a launcher for the game executable. The game executable and some of its files (models, scripts etc) are kept in an archive. My launcher extracts this archive to a temporary location on disk and runs the game from there. Would it be possible to extract these files to memory and run them from there? If so, how would I go about it? And would they be able to access other files on the hard-disk? A bigger problem is that using memory files would consume RAM that the game needs. As I have no way of accessing the file loading code of the game engine (it has an SDK but it is fairly limited in that respect, mainly aimed at adding graphics capabilities), I cannot tell the game executable to load files into memory, open them, then destroy them...
If anyone can think of a better solution than the one I am currently using, I would be really grateful... If not, I'd still be grateful for some help with cancelling MoveFileEx!
Many thanks, all help much appreciated,
KB
|
|
|
|
|
I want that if i press right mouse button over dialog button it press, if left mouse button - not. How can i do it?
Visual Studio C++6.0
Sorry for my Englsh
|
|
|
|
|
The simplest solution would be to process the WM_LBUTTONDOWN message and resend or repost it as a WM_RBUTTONDOWN message or call the routine that handles it.
MFC Example:
void OnLButtonDown(UINT nFlags,CPoint point)
{
OnRButtonDown(nFlags,point);
}
C/C++:
LRESULT CALLBACK winProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
switch(uMsg)
{
case WM_LBUTTONDOWN:
return SendMessage(hwnd,uMsg,wParam,lParam);
}
return 0;
}
INTP
|
|
|
|
|
I set background bitmap for my MDIChildWnd >>> okay
void CTest2View::OnPaint()
{<br />
CPaintDC dc(this);
}
but When I resize MDIChildWnd, it 's flicker
I can not fix it
help me
|
|
|
|
|
Normaly you would draw the background image in OnEraseBkgnd() which might solve part of your problem. Alternatly you can over ride OnEraseBkgnd(), so that it does not erase the background before OnPaint() is called, and do all the drawing in OnPaint().
There are some articles at codeproject on this subject and it is probably addressed in the FAQs.
INTP
|
|
|
|
|
Could you show me more detail about this ?
You mean: I do paint in CMDIChildWnd based class or CFormView based class of MDIChildWnd ?? in class which derive from CFormView have no WM_ERASEBKGND message ?!
I also do paint in both but not result, when resize it still flicker.
help me.......thanks
|
|
|
|
|
1) Search for articals on flicker free drawing (at codeproject).
Example: "Do a flicker-free drawing using MFC methods"
2) SDI, MDI, and Form windows are all directly or indirectly derived from CWnd which does receive a WM_ERASEBKGND message:
Example: CWnd->CView->CScrollView->CFOrmView.
Good luck!
INTP
|
|
|
|
|
Is it possible to send exactly 35 bits through the serial port?
To those who didn't make it, we will remember you. To those who did is back. - Megan Forbes in Black FridayAnother Post by NnamdiOnyeyiri
|
|
|
|
|
Very difficult if at all !
It would involve direct control over the UART which in turn would require disabling the device driver. Also, you still need start and stop bits so you wouldn't have control over all 35 bits.
Elaine
The tigress is here
|
|
|
|
|
damn. that really screws up my idea. so there is noooo way of doin it without the start and stop bits?
To those who didn't make it, we will remember you. To those who did is back. - Megan Forbes in Black FridayAnother Post by NnamdiOnyeyiri
|
|
|
|
|
Sorry hon, asynchronous format always has one start bit and 1, 1.5 or two stop bits with 5 to 8 data bits
Elaine (apologetic fluffy tigress)
The tigress is here
|
|
|
|
|
Depending on the capabilites of your serial communications chip, you may be able to program it for "synchronous communications" which does not involve the start/stop bits previously (and correctly) refered to.
It is a fairly involved process and requires a fairly good understanding of the hardware involved, but it is usually possible.
read the article in the latest help from MSDN entitled "Aristocratic Communication: NetBIOS", particularily the part about how to setup synchronous communications and how to control the UART from your program.
|
|
|
|
|
Why do you need to send exactly 35 bits through the serial port?
- Nigel
|
|
|
|
|
an little enlectronics project i was planning on doing. but no im lookin for a way around not being able to send the 35bits, by incorporating more stuff into the electronics side.
To those who didn't make it, we will remember you. To those who did is back. - Megan Forbes in Black FridayAnother Post by NnamdiOnyeyiri
|
|
|
|
|
Nnamdi Onyeyiri wrote:
Is it possible to send exactly 35 bits through the serial port?
It is, but only by using RTS and CTS as the data lines and doing the timing in software. Not pleasant, but possible.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
last night ive worked out what i think may work using a hardware approach to my problem, just have to work out how to program this microcontroller.
To those who didn't make it, we will remember you. To those who did is back. - Megan Forbes in Black FridayAnother Post by NnamdiOnyeyiri
|
|
|
|
|
Nnamdi Onyeyiri wrote:
last night ive worked out what i think may work using a hardware approach to my problem, just have to work out how to program this microcontroller.
Which microcontroller?
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
PICmicro 16F84 - right now im trying to find out how to send/recieve data on its pins.
To those who didn't make it, we will remember you. To those who did is back. - Megan Forbes in Black FridayAnother Post by NnamdiOnyeyiri
|
|
|
|
|
Nnamdi Onyeyiri wrote:
PICmicro 16F84 - right now im trying to find out how to send/recieve data on its pins.
Pretty cool little chip, huh?
I think MPLAB comes with some sample code for using two of the pins as a UART. There is an application note here[^] which details how to do it (AN555).
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
cool, thanks for the link, maybe ill make things easier for me, seeing as i have no idea what im doin
To those who didn't make it, we will remember you. To those who did is back. - Megan Forbes in Black FridayAnother Post by NnamdiOnyeyiri
|
|
|
|
|
hmmm, not to sure about that code, i had planned on using this[^] chip as a RS232, but thought that to control the CTS pins etc, i would still need the microcontroller. am i right?
To those who didn't make it, we will remember you. To those who did is back. - Megan Forbes in Black FridayAnother Post by NnamdiOnyeyiri
|
|
|
|
|
Nnamdi Onyeyiri wrote:
this[^] chip
That's an RS-232 level-shifter. RS-232 uses 0V for logic 0, and -12V for logic 1 (either that or the other way around). The level shifter is used to convert to/from standard logic (0=0V,1=5V). It doesn't process the data at all.
You'll still need a microcontroller to receive/transmit the signals, both the data and the CTS pins.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
ok, back to square 1, ill take another look at that link u gave me
To those who didn't make it, we will remember you. To those who did is back. - Megan Forbes in Black FridayAnother Post by NnamdiOnyeyiri
|
|
|
|