|
For a small list (small number of items) the Add/Delete will work (maybe add a CWnd::LockWindowUpdate rto prevent flickering)
You could also use the list box in "virtual mode".
This signature was proudly tested on animals.
|
|
|
|
|
Hi again,
I got another one. This time regarding mutexes. I am using the following locking routine:
HANDLE Thread::Lock( const char* name )
{
wchar_t buffer[FILENAME_MAX];
mbstowcs_s( NULL, buffer, FILENAME_MAX, name, FILENAME_MAX-1 );
HANDLE hMutex = CreateMutex(NULL,
FALSE,
buffer);
if (!hMutex)
{
return NULL;
}
if (GetLastError() == ERROR_ALREADY_EXISTS)
{
}
WaitForSingleObject(hMutex, INFINITE);
return hMutex;
}
Now I found out that my locking mechanism does not work properly. And the thing is this: Thread 1 calls the Lock()-function. A Mutex is created and everything is fine. While it is locked the same thread actually (which is an error, but that´s how I found out) calls the Lock()-function again with the same name parameter. CreateMutex returns a DIFFERENT handle this time but the GetLastError query returns ERROR_ALREADY_EXISTS. But since it is a different handle WaitForSingleObject() grants access again, before the first Unlock() call occured.
So how does this work. Shouldn´t I get the same handle everytime I call CreatMutex() with the same parameters? Otherwise I get a new handle everytime and nothing is really ever locked.
Thanks again.
Souldrift
|
|
|
|
|
Souldrift wrote: But since it is a different handle WaitForSingleObject() grants access again, before the first Unlock() call occured.
Or since the handle is to the same mutex and the thread already has a lock on it the wait call does not block.
Not all synchronization objects work the same, particularly when you lock them multiple times in the same thread. There are different object because they are designed to work differently.
Also I seriously recommend one obtains a good book on multi-threading if one intends to learn the subject.
|
|
|
|
|
The main problem here is that you are returning a local variable. In addition, every time your function is called, it creates a new mutex handle (referencing the same mutex.) You are leaking handles like crazy.
To properly use a mutex you need to first create it (and you don't need to do a conversion from a char to wide string--just call CreateMutexA.) The locking is done separately.
BTW, only use mutexes if you are synchronizing between processes or you have to have multiple waits on a lock, otherwise use critical sections.
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
It is not important the handle value of CreateMutex are different or same becuase the handle will never be compared its value but only be used with WaitForXXXXXX function.
Others wrote that mutex can not lock with the same thread and this implementation may cause handle leaks.
I suggest another locking mechanism using InterlockedIncrement and InterlockedDecrement like;
extern long some_locker = 0;
bool lock(long& name) {
if (1 == InterlockedIncrement(&name))
return true;
InterlockedDecrement(&name);
return false;
}
void unlock(long& name) {
InterlockedDecremtn(&name);
}
Note that this implementation dose not wait, so you must write wait loop for this for example;
while (!lock(some_locker)) Sleep(10);
unlock(some_locker);
This may not be quite your requirement, but one way of some practical technique.
|
|
|
|
|
Hi all
Can anybody tell me how to change the back ground color and text color dynamically in an edit box.
Thanks and regards
Deepu.
|
|
|
|
|
Check out WM_CTLCOLOREDIT .
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
|
I noticed the explorer properties that used to show in XP for my MFC generated files are gone in Vista. I did find something about including XML file .propdesc file to include properties that I need the file to have... Any one dealt with this before?
Thanks
|
|
|
|
|
Hi, does anyone know where sources for B/B+ tree implementation can be found?
The main requirements are:
- fast access to an element by index
- fast writing to a file
|
|
|
|
|
alikalik wrote: Hi, does anyone know where sources for B/B+ tree implementation can be found?
See here[^].
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
Nobody knows about, even Wikipedia [^], [^] (and you surely won't find links to C/C++ implementations at the bottom of the pages).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Hi
I have a MDI application. I don't want to use MDI default "ID_FILE_NEW". How can I manually implement this?
(1) What classes should I instance and create?
(2) The steps to do this?
Best regards,
|
|
|
|
|
transoft wrote: How can I manually implement this?
Implement what?
transoft wrote: (1) What classes should I instance and create?
To do what?
transoft wrote: (2) The steps to do this?
Steps for what?
Notice a theme here?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
Hi
I don't want to use MDI default "File-New" to instance a Child Window. I want to create Child Window myself. I need to do special processing during "File-New" process.
My question is: How can I implement the "File-New" operation without using MDI defaults? I don't want to use "Sending message "ID_File_New" message to Client window to get a Child Window. What is other way to do it (Instancing a new Child Window)?
Thanks,
|
|
|
|
|
Look in your app's BEGIN_MESSAGE_MAP() . See ID_FILE_NEW ? Just change the associated handler.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
That is what I don't want to do. I want to get rid of "ID_FILE_NEW". But I want to mimic the what "ID_FILE_NEW" does.
Do I need to instance and create "CSplitfrm", "CmyView, and "CMyDoc" class? How can I do it? what is sequence?
Thanks,
|
|
|
|
|
transoft wrote: I want to get rid of "ID_FILE_NEW".
Are you talking about the #define directive in afxres.h ?
transoft wrote: But I want to mimic the what "ID_FILE_NEW" does.
Have you looked at CWinApp::OnFileNew() ?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
It is so hard to explain what I want to do.
I want to totally forget ID_FILE_NEw. Just like there is no such "ID_FILE_NEW".
But I need to implement the same function (same with ID_FILE_NEW).
I know I have to do something with "CSplitfrm, CMyView, and CMyDoc" and set them up.
I want to know how to set all these up.
Thanks,
|
|
|
|
|
transoft wrote: I need to get rid of ID_FILE_NEW. Total forget it. Just like there is no such "ID_FILE_NEW".
Can't you just remove it (New) from the File menu?
transoft wrote: But I need to implement the same function (same with ID_FILE_NEW).
Which is why I suggested looking at CWinApp::OnFileNew()
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
I want to instance CSplitfrm, view and doc classes to implement this new Child window function.
I can not find "CWinApp::OnFileNew()" implementation.
Thanks,
|
|
|
|
|
transoft wrote: I can not find "CWinApp::OnFileNew()" implementation.
Did you look in appdlg.cpp ? It just calls the document manager's OnFileNew() method. Look in docmgr.cpp for that implementation.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
It is complicate. Is there an easier way?
Thanks,
|
|
|
|
|
OS Windows XP and Vista. I would like to work with virtual port USB of the printer through CreateFile, ReadFile, WriteFile (for data transfer in the printer to give the command on the print, to clear the printer buffer, to receive its status, to give Printer Page Description and Markup Languages commands, etc.). For me virtual printer port HP LaserJet 1020 in system is designated as USB001. I tried to use the port name in CreateFile (\. \\USB001), it has turned out nothing. Prompt how to work, please, with the virtual printer port. In the Internet has found nothing, only concerning virtual COM ports. Then it would be desirable to understand with virtual port of the scanner.
Alex Tumanov
|
|
|
|
|
tumanovalex wrote: For me virtual printer port HP LaserJet 1020 in system is designated as USB001. I tried to use the port name in CreateFile (\. \\USB001), it has turned out nothing.
No, you don't open a USB port directly. What you will need to do is get a handle to the driver for that device. So, you have to know the driver symbolic name and use this one instead.
But, what are you trying to achieve exactly ? Because if you need to print something, there's probably a much better way to do that than to access the printer driver directly...
|
|
|
|