|
I missed my last train !!!
prasad_som wrote: But, I wonder , why you are using dialog bar , in first place ?
Then , What should I used ?
"Success lies not in the result , But in the efforts !!!!!"
Amit Mistry - petlad -Gujarat-India
|
|
|
|
|
Why you are using dialog bar, when same can be achieved using dialog box ?
|
|
|
|
|
but there is one problem of title bar and frame, becoz I am using menu nevigation for each window.
except the about dialog all are IDD_DIALOGBAR, and I have set the postion(x,y) of all dialogs.
if is there any suggestion? ever welcome.
"Success lies not in the result , But in the efforts !!!!!"
Amit Mistry - petlad -Gujarat-India
|
|
|
|
|
i am working an application that uses a file for some purpose. i am creating that file by using CreateFile() function. Now, i want to make sure that no other application uses that File till me application closes. i.e, i want no other application to access the file (not even for reading) as long as my application is running. how can i do this?
Regards,
Srinivas
|
|
|
|
|
Use dwShareMode as NULL while using CreateFile API.
|
|
|
|
|
No, it is not working for me. i don't know what mistake i am doing. here is the sample code of what i have written
<br />
<br />
hFile = CreateFile ( strFileName,GENERIC_WRITE ,NULL,NULL,CREATE_ALWAYS ,FILE_ATTRIBUTE_NORMAL,NULL);<br />
<br />
after creation of the file, i write the data to that file. now i dont want any other application to access that File till i close my application. how can i do this? thanks..
Regards,
Srinivas
|
|
|
|
|
vasu_sri wrote: No, it is not working for me.
How you are verifying this.
vasu_sri wrote: now i dont want any other application to access that File till i close my application.
Yes, by above code, no other application could access the file, till handle is closed.
vasu_sri wrote: how can i do this?
Its already shown.
|
|
|
|
|
In addition to what Prasad said:
if you're using MFC and CFile , you should use the CFile::shareExclusive flag when opening the file.
Read more here[^].
"It's supposed to be hard, otherwise anybody could do it!" - selfquote "High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
HANDLE hFile = CreateFile(
psFile,
GENERIC_READ | GENERIC_WRITE,
0,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL);
DWORD dwErr = GetLastError();
...
CloseHandle(hFile);
|
|
|
|
|
If I call AddString() to add a string to a listbox,how can I get it in the structure lpDrawItemStruct in DrawItem?Is the string saved in lpDrawItemStruct->itemData?
And what is difference between calling AddString and SetItemData?
Thanks~
|
|
|
|
|
IT_DOER wrote: Is the string saved in lpDrawItemStruct->itemData?
Yes.
IT_DOER wrote: And what is difference between calling AddString and SetItemData?
Doesn't MSDN satisfy your query ?
|
|
|
|
|
I am refering to a example about ListBox,and it creates a function AddItem like this:
void CListBoxEx::AddItem(UINT IconID, LPCTSTR lpszText)
{
//Adds a string ans assigns nIndex the index of the current item
int nIndex=AddString(lpszText);
//If no error, associates the index with the bitmap ID
if (nIndex!=LB_ERR && nIndex!=LB_ERRSPACE)
SetItemData(nIndex, IconID);
}
It calls AddString and after it calls SetItemData,whether the data of string and the bitmap both are save in lpDrawItemStruct->itemData?I am puzzled~
And I call the AddString("1");
and get the string and in DrawItem like this:
CString* pt_str=(CString*)lpDrawItemStruct->itemData;
dc.TextOut(lpDrawItemStruct->rcItem.left+4,lpDrawItemStruct->rcItem.top+2,
*pt_str);
is it correct?
|
|
|
|
|
IT_DOER wrote: Is the string saved in lpDrawItemStruct->itemData
Yes, it is passed as lpDrawItemStruct->itemData in DrawItem , see the folowing excerpt from MSDN:
...
void CMyListBox::DrawItem(LPDRAWITEMSTRUCT lpDrawItemStruct)
{
ASSERT(lpDrawItemStruct->CtlType == ODT_LISTBOX);
LPCTSTR lpszText = (LPCTSTR) lpDrawItemStruct->itemData;
...
IT_DOER wrote: And what is difference between calling AddString and SetItemData?
with SetItemData , you can associate e 32-bit integer to each item of the list (it is a value completely independent from the item text ). Again, see the following sample from MSDN:
extern CListBox* pmyListBox;
for (int i=0;i < pmyListBox->GetCount();i++)
{
pmyListBox->SetItemData(i, i);
}
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.
|
|
|
|
|
I am refering to a example about ListBox,and it creates a function AddItem like this:
void CListBoxEx::AddItem(UINT IconID, LPCTSTR lpszText)
{
//Adds a string ans assigns nIndex the index of the current item
int nIndex=AddString(lpszText);
//If no error, associates the index with the bitmap ID
if (nIndex!=LB_ERR && nIndex!=LB_ERRSPACE)
SetItemData(nIndex, IconID);
}
It calls AddString and after it calls SetItemData,whether the data of string and the bitmap both are save in lpDrawItemStruct->itemData?I am puzzled~
|
|
|
|
|
IT_DOER wrote: It calls AddString and after it calls SetItemData,whether the data of string and the bitmap both are save in lpDrawItemStruct->itemData?
NO.
As I stated before, the text of the item is different (independent) from it's data (that is a 32-bit integer you can use as you like). The lpDrawItemStruct->itemData has nothing to do with SetItemData second argument.
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.
|
|
|
|
|
Mmm,in other words,I can call different function to get the string and the data I set in SetItemData~?
Thanks a lot~~
|
|
|
|
|
<blockquote class="FQ"><div class="FQA">CPallini wrote:</div>LPCTSTR lpszText = (LPCTSTR) lpDrawItemStruct->itemData;</blockquote>
For calling TextOut to output the string,I get the string from lpDrawItemStruct like this:
CString* pt_str=(CString*)lpDrawItemStruct->itemData;
dc.TextOut(lpDrawItemStruct->rcItem.left+4,lpDrawItemStruct->rcItem.top+2,
*pt_str);
and I called the AddString("1") before it.
Is it correct?If it is,why there is nothing in the ListBox when I run the program?I have set the style to "Has Strings"....
|
|
|
|
|
IT_DOER wrote: CString* pt_str=(CString*)lpDrawItemStruct->itemData;
The code above is wrong, you cannot cast lpDrawItemStruct->itemData to a CString * .
Please use the original code:
LPCTSTR lpszText = (LPCTSTR) lpDrawItemStruct->itemData;
and then
dc.TextOut(lpDrawItemStruct->rcItem.left+4,lpDrawItemStruct->rcItem.top+2,
lpszText);
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.
|
|
|
|
|
I have a class which sets a timer to fire every five minutes:
m_hTimer = ::SetTimer(NULL, NULL, 5*60*1000, MyTimerProc);
Dependent on circumstances, MyTimerProc() may need to ask for user intervention (for simplicity I'll use an AfxMessageBox()). Obviously I don't want the AfxMessageBox to pop up multiple times should the program be unattended for a period of time. I have come up with the following:
void CALLBACK MyTimerProc(HWND hWnd, UINT nMsg, UINT nIDEvent, DWORD dwTime)<br />
{<br />
static bool locked = false;<br />
<br />
if (!locked)<br />
{<br />
locked = true;<br />
AfxMessageBox("HELLO");<br />
locked = false;<br />
}<br />
}
Of course, I'd rather be using something safer than the frankly dodgy static variable. But EnterCriticalSection() et al don't work (they merely increment the LockCount and RecursionCount without blocking), and the CreateMutex()/WaitForSingleObject() method seems to suffer from the same problem.
I think the problem is down to each successive SetTimer() event being seen as being in the same thread.
Anybody been here before? Any suggestions gratefully received!
|
|
|
|
|
EnterCriticalSection(...) is working correctly in this case - if the same thread tries to enter the same CS, it just increments the counters.
I think that using the static variable may be the easiest way to make this kind of issue work, short of not throwing up a blocking interface. There is no need to take something simple that works and make it unnecessarily complex.
If the number of times the message would have been shown is significant, I would suggest having a custom dialog where you can update a message or counter indicating multiple messages (like: "this message has occurred xxx times").
Peace!
-=- James Please rate this message - let me know if I helped or not!<HR> If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong! Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road! See DeleteFXPFiles
|
|
|
|
|
Just a thought:
1.
Stop the timer in the callback function.
2.
Display the message.
3.
(Re)start the timer.
Alcohol. The cause of, and the solution to, all of life's problems - Homer Simpson
|
|
|
|
|
Considering that the OP wrote:
Dependent on circumstances, MyTimerProc() may need to ask for user intervention [...] - It sounds like the timer function is doing something other than showing a message box. Because of that, stopping the time may not be such a good idea...
Peace!
-=- James Please rate this message - let me know if I helped or not!<HR> If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong! Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road! See DeleteFXPFiles
|
|
|
|
|
Then, just stop the timer when the messagebox has to be shown. The timer proc (I assume) will have to wait for a response anyway.
Else, another way could be to let the timer proc start a thread that shows the messagebox. That way, the thread can keep on working, and the thread is responsible for getting input from the message box.
Alcohol. The cause of, and the solution to, all of life's problems - Homer Simpson
|
|
|
|
|
Killing, then re-enabling the timer looks to be the way forward. A little annoyed I didn't think of it myself!
Thanks for the input everyone!
|
|
|
|
|
I'm glad to be able to help you out.
And sometimes, the simplest answers are the hardest to find.
Alcohol. The cause of, and the solution to, all of life's problems - Homer Simpson
|
|
|
|