TopComponent win = new MyTopComponent(); win.open(); win.requestActive();If you wrote your persistence code correctly, your components will magically reopen on restart with no further work.
depends.exe)depends.exe-console,
possibly -p profilename, possibly -mail ...)depends.exec:\windows> depends /pa1
/pd"c:\program files\mozilla"
/pr"-console"
/od"desktop\mozilla.dwi" "c:\program files\mozilla\mozilla.exe"c:\windows> depends /c
/a
1
/f
1
/u
1
/ps
1
/pp
1
/po
1
/ph
1
/pl
1
/pg
1
/pt
1
/pn
1
/pe
1
/pm
1
/pf
1
/pc
1
/pb
/pd"c:\program files\mozilla"
/pr"-console"
/od"desktop\mozilla.dwi" "c:\program files\mozilla\mozilla.exe"/pa1 /pc0 will run
Dependency Walker with all options except for pc (Automatically
open and profile child processes).
On This Page
INTRODUCTION
|
|
IP Address 192.168.0.2
Subnet mask 255.255.255.0
Default gateway 192.168.0.1
|
|
|
|
REFERENCES| TCP | UDP |
| Reliability: TCP is connection-oriented protocol. When a file or message send it will get delivered unless connections fails. If connection lost, the server will request the lost part. There is no corruption while transferring a message. | Reliability: UDP is connectionless protocol. When you a send a data or message, you don't know if it'll get there, it could get lost on the way. There may be corruption while transferring a message. |
| Ordered: If you send two messages along a connection, one after the other, you know the first message will get there first. You don't have to worry about data arriving in the wrong order. | Ordered: If you send two messages out, you don't know what order they'll arrive in i.e. no ordered |
| Heavyweight: - when the low level parts of the TCP "stream" arrive in the wrong order, resend requests have to be sent, and all the out of sequence parts have to be put back together, so requires a bit of work to piece together. | Lightweight: No ordering of messages, no tracking connections, etc. It's just fire and forget! This means it's a lot quicker, and the network card / OS have to do very little work to translate the data back from the packets. |
| Streaming: Data is read as a "stream," with nothing distinguishing where one packet ends and another begins. There may be multiple packets per read call. | Datagrams: Packets are sent individually and are guaranteed to be whole if they arrive. One packet per one read call. |
| Examples: World Wide Web (Apache TCP port 80), e-mail (SMTP TCP port 25 Postfix MTA), File Transfer Protocol (FTP port 21) and Secure Shell (OpenSSH port 22) etc. | Examples: Domain Name System (DNS UDP port 53), streaming media applications such as IPTV or movies, Voice over IP (VoIP), Trivial File Transfer Protocol (TFTP) and online multiplayer games etc |
Back to the top
BOOL CreateTimerQueueTimer(PHANDLE phNewTimer, HANDLE TimerQueue ,
WAITORTIMERCALLBACK Callback, PVOID Parameter, DWORD DueTime,
DWORD Period, ULONG Flags);
phNewTimer - Pointer to a handle; this is an out valueTimerQueue - Timer queue handle. For the default timer queue, NULLCallback - Pointer to the callback functionParameter - Value passed to the callback functionDueTime - Time (milliseconds), before the timer is set to the signaled state for the first time Period - Timer period (milliseconds). If zero, timer is signaled only onceFlags - One or more of the next values (table taken from MSDN):WT_EXECUTEINTIMERTHREAD |
The callback function is invoked by the timer thread itself. This flag should be used only for short tasks or it could affect other timer operations. |
WT_EXECUTEINIOTHREAD |
The callback function is queued to an I/O worker thread. This flag should be used if the function should be executed in a thread that waits in an alertable state. The callback function is queued as an APC. Be sure to address reentrancy issues if the function performs an alertable wait operation. |
WT_EXECUTEINPERSISTENTTHREAD |
The callback function is queued to a thread that never terminates. This flag should be used only for short tasks or it could affect other timer operations. Note that currently no worker thread is persistent, although no worker thread will terminate if there are any pending I/O requests. |
WT_EXECUTELONGFUNCTION |
Specifies that the callback function can perform a long wait. This flag helps the system to decide if it should create a new thread. |
WT_EXECUTEONLYONCE |
The timer will be set to the signaled state only once. |
VOID CALLBACK WaitOrTimerCallback(PVOID lpParameter, BOOLEAN TimerOrWaitFired);
lpParameter - Pointer to user-defined dataTimerOrWaitFired - always TRUE for timer callbacksBOOL DeleteTimerQueueTimer(HANDLE TimerQueue, HANDLE Timer, HANDLE CompletionEvent);
TimerQueue - A handle to the (default) timer queueTimer - A handle to the timerCompletionEvent - A handle to an optional event to be
signaled when the function is successful and all callback functions have
completed. Can be NULL.void CTimersDlg::OnButtonBegin()
{
.
.
.
// create the timer
BOOL success = ::CreateTimerQueueTimer(
&m_timerHandle,
NULL,
TimerProc,
this,
0,
elTime,
WT_EXECUTEINTIMERTHREAD);
}
void CTimersDlg::OnButtonStop()
{
// destroy the timer
DeleteTimerQueueTimer(NULL, m_timerHandle, NULL);
CloseHandle (m_timerHandle);
}
void CTimersDlg::QueueTimerHandler() // called every elTime milliseconds
{
// do what you want to do, but quickly
.
.
.
}
void CALLBACK TimerProc(void* lpParametar,
BOOLEAN TimerOrWaitFired)
{
// This is used only to call QueueTimerHandler
// Typically, this function is static member of CTimersDlg
CTimersDlg* obj = (CTimersDlg*) lpParametar;
obj->QueueTimerHandler();
}
As you can see, queue timers are pretty easy to use. I can also add that they are very accurate, and "resource friendly".