|
Include ws2tcpip.h
I highly recommend IOCP for multiclient servers. There are several factors to consider when deciding on IOCP or multithreading such as OVERLAPPED and event driven I/O. One is connection. Given that 100 clients connect in within 1 sec, IOCP surpasses all other nonblocking I/O. Overall, the benefit of I/O is in the handling of thousands of clients with limited or any lag or loss of data.
Kuphryn
|
|
|
|
|
Cool, thanks! 
Kuniva
--------------------------------------------
|
|
|
|
|
ack.. now i have another problem, it still seems to include winsock.h somehow because when i try to compile it gives me a lot of redefinition errors between winsock.h and WS2tcpip.h (like IP_TOS, IP_TTL etc).
Kuniva
--------------------------------------------
|
|
|
|
|
Include winsock2.
Kuphryn
|
|
|
|
|
Hi,
I'm writing an application that stores some temporary files on disk and deletes them on closing (there is no way around this). To be tidy, I want to tell the application to delete the files if the computer is restarted whilst it is running, and thus I have used MoveFileEx with MOVEFILE_DELAY_UNTIL_REBOOT for Win2000 etc, and the WinInit.ini file for Windows 9x.
When the program ends, it is easy to cancel the "DeleteFileOnReboot" function I am using for Win 9x, as all I have to do before amending WinInit.ini is check if it exists (if it doesn't I can just create it then delete it on closing), and if it does save its settings using GetPrivateProfileSection and then restore them when my app ends using WritePrivateProfileSection.
However, I have no idea how to cancel MoveFileEx for Win2000/NT/XP platforms, as this stores all the files to be deleted in the registry. (I am a relative novice, and have never played with the registry before in an application.)
MSDN gives the following info:
[quote]
The function stores the locations of the files to be renamed at restart in the following registry value:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations
This registry value is of type REG_MULTI_SZ. Each rename operation stores the following pair of NULL-terminated strings:
szDstFile\0\0
szSrcFile\0szDstFile\0\0
[/quote]
Unfortunately, I have no idea how to use this information... If anybody could tell me how I can cancel MoveFileEx after it has been called for files using the MOVEFILE_DELAY_UNTIL_REBOOT flag, I would be really grateful.
Many thanks,
KB
P.S. I am using the straight Windows API with *no* MFC.
|
|
|
|
|
IMO you're approaching the problem the wrong way. Instead of complicated logic involving INI files and cancelling API calls, just keep a list of the temp files you create. In your app's shutdown code, go thru the list and delete the files. You can handle WM_QUERYENDSESSION and WM_ENDSESSION to know when the computer is being shut down.
--Mike--
Ericahist | Homepage | RightClick-Encrypt | 1ClickPicGrabber
Latest art~!@#2rDFA#@(#*%$Rfa39f3fqwf--=
NO CARRIER
|
|
|
|
|
Thank you for your reply, much appreciated - this is really useful information. I didn't even know about these messages (my knowledge is fairly limited as I'm in the process of learning).
Unfortunately this isn't really a solution, though, from what I have read on MSDN. If a user hits the "power off" button or the "reboot" button on his (or her) PC, the WM_QUERYENDSESSION and WM_ENDSESSION messages won't get sent, meaning the files will be left on the harddrive. So unless I am totally wrong about this, I guess I am stuck with trying to find out how to delete the relevant MoveFileEx info from the registry...
Many thanks for any help,
Cheers,
KB
|
|
|
|
|
Think of it this way: how often is the user going to turn off the power? How often is he going to shut your program down normally? How often will he log off/restart with your app open? I'd wager 1 power-off for 1000 normal shutdowns. Handling that 1 power-off is making your code much more complicated and harder to maintain, and as you've seen, you might not even be able to handle your clean-up properly. Why break your code for that 1 case? If the user cuts power, tough for him, other programs aren't going to handle it right either.
--Mike--
Ericahist | Homepage | RightClick-Encrypt | 1ClickPicGrabber
Latest art~!@#2rDFA#@(#*%$Rfa39f3fqwf--=
NO CARRIER
|
|
|
|
|
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![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif)
|
|
|
|
|
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 ![Green Alien | [Alien]](https://www.codeproject.com/script/Forums/Images/alien.gif) 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"
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
