|
I've never seen this problem before... but then again, I don't work with .Net regularly.
|
|
|
|
|
Thanks everybody,
my problem is solved. it's the problem of path setting for .resx file.
|
|
|
|
|
Knowing where files are certainly makes programs work better
|
|
|
|
|
From MSDN "Workspace coordinates differ from screen coordinates in that they take the locations and sizes of application toolbars (including the taskbar) into account. Workspace coordinate (0,0) is the upper-left corner of the workspace area, the area of the screen not being used by application toolbars"
I am very comfused about the paragraph above. I know what taskbar is, it locates in the bottom of my screen, containing application icons.but what is application toolbars? It sure doesn't mean the toolbar on the app UI that resembles the menu functions.
could someone help me?
|
|
|
|
|
Between Windows 95 and Windows Vista, you used to be able to have multiple-docked toolbars called "deskbands", like a Address deskband docked to the left side of the screen.
Like the Tasbar, Deskbands could be set to Autohide. If they aren't hidden, then the available workarea is reduced. Here is code that I use to find out the available work area:
printf("Work Area size:\t");
RECT rectWorkArea;
bool bSuccess = SystemParametersInfo(SPI_GETWORKAREA, 0, &rectWorkArea, 0);
/* Charles Oppermann */
http://weblogs.asp.net/chuckop
|
|
|
|
|
I use WINXP. All I know is the taskbar can be docked to the four sides of the screen and can be autohided.How can I bring up the application toolbar ?
|
|
|
|
|
Check this link:
http://en.wikipedia.org/wiki/Taskbar#Desktop_toolbars[^]
Right-click on the taskbar, choose toolbars, pick one. Ensure the Taskbar is Unlocked and then drag the new toolbar off and over to another edge.
/* Charles Oppermann */
http://weblogs.asp.net/chuckop
|
|
|
|
|
If i insert some items say 500 or more than it in list control then flickering problem occur. I have tried to create secondary thread and insert items from list control from thread but the flickering problem still exist. I hface same problem in tree control also.
Please suggest how to solve it.
|
|
|
|
|
Before you update the list control with the 500 items, make a call to
SetRedraw(FALSE); Once you are completed adding the 500 items, you then call
SetRedraw(TRUE);
Chris Meech
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
|
|
|
|
|
With this number of items you may want to consider using a virtual (owner drawn) listview.
Unrequited desire is character building.
|
|
|
|
|
LVS_EX_DOUBLEBUFFER[^]
m_ListCtrl.SetExtendedStyle(m_ListCtrl.GetExtendedStyle() | LVS_EX_DOUBLEBUFFER);
|
|
|
|
|
I'm developing a driver based on the SWTuner sample from the WinDDK. The driver receives MPEG-TS data from an application, and for debugging purposes I want the driver to dump the data to file.
My problem with closing the file handle: Calling ZwClose in a procedure timed with KeSetTimer causes a bluescreen with the message INVALID_PROCESS_ATTACH_ATTEMPT.
In more detail:
The driver receives a request from the application to open the file (works fine) and then writes the incomming buffers to file (also works fine). The problem is with closing the file handle: To avoid a locked file, a KTIMER is set to 10 seconds every time the the file handle is opened or written to (see method ResetTimeoutTimer). The procedure assigned to the timer is supposed to close the file handle (see method TimeoutTimerDPC).
Problem: The procedure TimeoutTimerDPC gets called 10 seconds after the last write, so this part works. With ZwClose commented out, the procedure works fine (pDevice can be accessed, debug output is generated). But when TimeoutTimerDPC calls ZwClose(pDevice->m_FileHandle) , this results in a blue screen with INVALID_PROCESS_ATTACH_ATTEMPT.
Any ideas what I'm doing wrong here, and how to fix it?
bool m_test_dump_file_open;
HANDLE m_FileHandle;
PRKDPC m_FileTimeoutDpc;
KTIMER m_FileTimeoutTimer;
CDevice::
Handle_IOCTL_Open(CDevice * pDevice,
PIRP Irp,
PIO_STACK_LOCATION pIoStackIrp,
UINT *pdwDataWritten)
{
PAGED_CODE();
UNICODE_STRING FileName;
RtlZeroMemory(&FileName, sizeof(FileName));
RtlInitUnicodeString(&FileName,
L"\\DosDevices\\C:\\media\\pbda_driver_dump.ts");
OBJECT_ATTRIBUTES FileObject;
IO_STATUS_BLOCK IoStatus;
NTSTATUS Status;
InitializeObjectAttributes(&FileObject,
&FileName,
OBJ_CASE_INSENSITIVE | OBJ_KERNEL_HANDLE,
NULL,
NULL);
Status = ZwCreateFile(&(pDevice->m_FileHandle),
FILE_APPEND_DATA | SYNCHRONIZE,
&FileObject,
&IoStatus,
NULL,
FILE_ATTRIBUTE_NORMAL,
FILE_SHARE_WRITE,
FILE_SUPERSEDE,
FILE_SYNCHRONOUS_IO_NONALERT,
NULL,
0);
PAGED_CODE();
KeInitializeTimer (&(pDevice->m_FileTimeoutTimer));
pDevice->m_FileTimeoutDpc = new(NonPagedPool,MS_SAMPLE_TUNER_POOL_TAG) KDPC;
KeInitializeDpc (pDevice->m_FileTimeoutDpc,
reinterpret_cast <PKDEFERRED_ROUTINE> CDevice::TimeoutTimerDPC),
pDevice );
ResetTimeoutTimer(pDevice);
return Status;
}
CDevice::
ResetTimeoutTimer(CDevice * pDevice)
{
KIRQL MySpinIrql;
KeAcquireSpinLock(&(pDevice->m_buffer_queue_lock), &MySpinIrql);
LARGE_INTEGER NextDeltaTime;
NextDeltaTime.QuadPart = (-100000000); KeCancelTimer(&(pDevice->m_FileTimeoutTimer));
KeSetTimer (&(pDevice->m_FileTimeoutTimer),
NextDeltaTime,
pDevice->m_FileTimeoutDpc);
KeReleaseSpinLock(&(pDevice->m_buffer_queue_lock), MySpinIrql);
}
void
CDevice::
TimeoutTimerDPC (
IN PKDPC Dpc,
IN CDevice *pDevice,
IN PVOID SystemArg1,
IN PVOID SystemArg2
)
{
UNREFERENCED_PARAMETER(Dpc);
UNREFERENCED_PARAMETER(SystemArg1);
UNREFERENCED_PARAMETER(SystemArg2);
KIRQL MySpinIrql;
KeAcquireSpinLock(&(pDevice->m_buffer_queue_lock), &MySpinIrql);
NTSTATUS Status;
if(pDevice){
Status = ZwClose(pDevice->m_FileHandle); }
KeReleaseSpinLock(&(pDevice->m_buffer_queue_lock), MySpinIrql);
}
|
|
|
|
|
I believe the issue is related to the fact that the file handle can't be closed by a thread other than the one that created it.
In your case, the ZwClose is being used inside an asynchronous procedure.
By the way, I do'nt understand why you defer that in a KTIMER in the name of "avoiding a locked file".
Push Framework - now released !
http://www.pushframework.com
|
|
|
|
|
WS_OVERLLAPED 0x0L
WS_POPUP 0x80000000L
I don't really understand the differences between them. They both can have border, min/max button, or sysmenu. The only different feature I can read from msdn is popup cannot be a child window. so is that all these two are different?
Can I take the popup window this way? popup window is overlapped too, coz all window is overlapped(WS_OVERLAPPED = 0x0L),the 31th bit of the window style is set to 1 to indicate that it mustn't be a child window, but it can be an owned window.so they are different only when they are being owned?(I don't know child window can be said " being owned" either, coz being owned and being a child are totally different. )
|
|
|
|
|
WS_OVERLAPPED creates a window with a frame border, WS_POPUP creates a similar window but without the frame border. You can test this by creating a very simple Win32 application and try the various styles to see the different effects.
Unrequited desire is character building.
|
|
|
|
|
That's what I would've done (test it)... but I had no idea as to the difference...
|
|
|
|
|
I have tested a lot. Turns out having the WS_POPUP(0x80000000) bit on doesn't mean adding a feature to a window,but means eliminating a feature from a window. That feature is the title bar. If missing WS_POPUP we normally have no way to create a window without caption bar,however POPUP window still can be forced to have title bar if combined with WS_CAPTION,that's it changes back to a OVERLAPPED window again.Popup window cannot be a child window too.I think overlapped window, popup window and child window are mutually exclusive, only because overlapped window is the value 0x0, so if we use WS_OVERLAPPED | WS_CHILD doesn't affect the success to creating the window.But the msdn says WS_OVERAPPED is a top-level window which means WS_OVERALPPED conceptually cannot be a child window too.
|
|
|
|
|
Albert Holguin wrote: I had no idea as to the difference
Nor me; I just ran a quick test to see it. I have to admit that the description in MSDN is very poor for anyone trying to learn about the differences.
Unrequited desire is character building.
|
|
|
|
|
Richard MacCutchan wrote: the description in MSDN is very poor
...that happens a lot...
|
|
|
|
|
Hi all,
I am trying to write a file in binary mode using _tfopen_s function.
My problem is i have to write it first then i have to close it and then after some time i need to open it and write contents at the end of it and then close it again.
i am using these lines to do this
_tfopen_s(&fileptr, File_Path, _T("wb+") );
fwrite ( buffer1, 25, 1, fileptr );
fclose(fileptr);
and
_tfopen_s(&fileptr, File_Path, _T("ab") );
fwrite ( buffer1, 25, 1, fileptr );
fclose(fileptr);
but my problem is when i am trying to open that file it is not opening
Is there anything that i am doing wrong in writing the file.
thanks in advace
|
|
|
|
|
Check the return value of the open that fails, it's an error code, it probably can shed some light on the issue.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> //TODO: Implement signature here<
|
|
|
|
|
Error checking is like a cataract operation!!!
|
|
|
|
|
Hello there,
I am using a MDI application in MFC to display images...
I want to use the double-click event to make the child window appear in full-screen mode and double-click again to put back in to the previous size.
Any suggestions to do this?
Thanks in advance!!
|
|
|
|
|
|