|
Ofcourse you could render that area yourself but, and trust me on this:
Since only one window will have the focus do not try to trick the user into thinking otherwise.
I personally would despise any programmer involved in such a program. Ok, that maybe a bit much but the point is: obey the rules dammit! 
|
|
|
|
|
I have an API program in which I have one thread other than the main thread. In the other thread, I wrote MessageBox(globalMainWndHWND, ...), trying to get a message under my main window. The problem is that at this step the MessageBox function does not return! I thought that Windows might prevent threads from using objects created by other threads. I tried to pass the HWND as a parameter to the thread function (instead of using the global variable), but the same problem happened again. SendMessage did the same thing. Could someone please tell me how I could solve this problem? Thank you very much.
Hosam Aly Mahmoud
|
|
|
|
|
If the secondary thread does not have its own message pump (i.e., worker thread), calling MessageBox() in it will effectively block the message pump in the primary thread.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
Thanks for your reply, but could you point out an alternative?
Hosam Aly Mahmoud
|
|
|
|
|
Can I see if I can clarify the question?
At this point in the secondary thread, you want to cause a message box to be displayed, but you want your secondary thread to continue running even though there's a message box up.
To do this, you'll need to post a message to your primary thread (probably to the main window) to cause it to create the message box, using PostMessage. Unlike SendMessage, PostMessage is non-blocking - it returns immediately after adding the message to the message queue of the thread that owns the window.
SendMessage blocks the sending thread until the receiving thread responds, by either returning from the window procedure or by calling ReplyMessage (desktop only; Windows CE does not offer this function). The return value of SendMessage is the return value of the window procedure, or the value passed to ReplyMessage.
|
|
|
|
|
Thanks for your help.
I am sorry to say that your clarification missed a bit. I want to stop the secondary thread, and get out the message box. After the message box returns yes or no, the secondary thread will do work according to the user's choice. But thanks for your help anyway! ![Rose | [Rose]](https://codeproject.freetls.fastly.net/script/Forums/Images/rose.gif)
Hosam Aly Mahmoud
|
|
|
|
|
Hi,
I am trying to convert the existing project that I am working on which is in Visual C++6 to Visual C++.NET. When I installed Visual Studio.NET and tried to open the project, it put up a message box saying that the project needs to be converted to version 7. When I hit the Yes button, the whole thing crashed.
I don`t think there is anything wrong with the installation. Everything else is working fine, including all teh 3 languages (VB, C# & C++) and also, the same utility is SUCCESSFULLY converting several smaller projects into .NET.
Does anybody ahve a clue????
Thanks in advance,
(vinod)
|
|
|
|
|
No clue, just a suggestion: don't convert the project, recreate it from scratch. It shouldn't be too difficult or time-consuming. It may just be that your old project has been customized in ways that VC.NET can't deal and then it gets a heart attack.
Regards,
Alvaro
Hey! It compiles! Ship it.
|
|
|
|
|
Thanks for taking the time. I know what you mean, but I am trying to avoid that route becuase this one creates 18 DLLs and 1 EXE, in a single project. So, recreating it in .NET with all the options and flags will be a tricky & time-consuming process. Hence my reluctance....
But, THANKS again....
regards,
(vinod)
|
|
|
|
|
 18 DLLs? Talk about modularization!
It sounds like you're gonna be spending some time recreating it. Yet another alternative may be to make VC.NET convert each project (DLL) individually and at the end put them all together under one solution.
Good luck!
Alvaro
Hey! It compiles! Ship it.
|
|
|
|
|
I have an SDI application and it requires the use of multiple text files for it's input. I originally had no problems with using these files for input. Now, the program will crash if the user opens their file (through File -> Open) before an input file is opened. I'm pretty sure it's because the application is an SDI. The only reason why the user needs to open a file is because I need the filename, I don't care what's actually in the file that they want to open. Is there another way that I could obtain this filename, without actually opening the file, but with still having the user believe that it has been opened?
Sorry if this is a bit confusing, I can't think of any other way to explain it.
|
|
|
|
|
This sounds more like an Options or Configuration dialog sort of thing.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
The text files that the program uses for input have nothing to do with the file that the user selects to open. The user doesn't even know that these files are being used. That is why it was decided to stick with the typical File -> Open. By the time I'm done with this, it may be necessary to actually use this file the user wants to open, but for now it's not required.
I was just wondering if there was any way to have more than one file open at a time when using SDI?
|
|
|
|
|
Like David mentioned, you may want to consider creating an "Options" dialog box where the user can tell you the name of the file(s), and you can save that in the registry or something similar.
Opening multiple files should be no problem -- use the CFile class. Showing them is another story. If it's an SDI app then you can only show one at a time. But perhaps you don't even care about showing the files. If that's the case don't complicate your life with SDI or MDI. Create a dialog-based app and add all the controls you need to it.
Regards,
Alvaro
Hey! It compiles! Ship it.
|
|
|
|
|
I'm not displaying any of the file information (as of yet). The files unknown to the user are used mainly for storing output, and reading for input.
Using other files for input/ouput works just fine if the user never "opens" a file. As soon as the user does this, it seems to not create any of the other files required for the output.
In my CMainFrame constructor I have:
CMainFrame::CMainFrame()
{
m_fileName = "inputParams.txt"; //used first for output, later as input
CFile m_filePtr(m_fileName, CFile::modeCreate);
}
Later on, a modeless dialog opens up which first attempts to open m_fileName for reading. It will successfully do this as long as the user has not "opened" a file:
BOOL CSetupModeless::OnInitDialog()
{
CDialog::OnInitDialog();
CFileException e;
CFile paramFilePtr = ((CMainFrame*)m_parent)->m_filePtr;
paramFileName = ((CMainFrame*)m_parent)->m_fileName;
//attempt to open inputParams.txt for reading only
if((paramFilePtr.Open(paramFileName, CFile::modeRead, &e )) == false )
{
//it will only come in here if user "opened" a file first
AfxMessageBox("error");
}
else
{
//it will come in here all the time, until
//the user "opens" a file... this is where it should go!
}
return TRUE;
}
Anyone know what would stop it from entering into the else when the user "opens" a file?
|
|
|
|
|
I notice a couple of glaring problems with your code:
1. In your CMainFrame constructor you initialize the m_filePtr member, but in reality you're not! All you're doing is creating a local variable called m_filePtr, which then immediately gets destroyed when the constructor exits. You should do it this way instead:
CMainFrame::CMainFrame()
{
m_fileName = "inputParams.txt";
m_filePtr.Open(m_fileName, CFile::modeCreate);
}
OR even better,
CMainFrame::CMainFrame() :
m_fileName("inputParams.txt"),
m_filePtr(m_fileName, CFile::modeCreate)
{
}
2. Inside your OnInitDialog, you should retrive a reference to your m_filePtr member, not a copy (although I'm not sure what that does):
CFile& paramFilePtr = ((CMainFrame*)m_parent)->m_filePtr;
I hope this helps.
Regards,
Alvaro
Hey! It compiles! Ship it.
|
|
|
|
|
I'll try fixing that up a bit tomorrow... I see what you mean about what I had in my MainFrame constructor, although it confuses me as to why it would work every other time I ran my program (always works as long as the user never actually opens a file)...
Thanks a lot for your help... and hopefully I'll get this all straightened out!
|
|
|
|
|
The frame object should not have anything to do with files. It's for frame manipulation. Having a CFile object anywhere near it is a fundamentally bad idea.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
So then where should I be attempting to create this file? I need this file to exist throughout the entire program execution, so I don't want to create it every time the modeless dialog that uses it opens up.
Is it best to maybe put that CFile object inside the Doc class?
|
|
|
|
|
b_girl wrote:
...so I don't want to create it every time the modeless dialog that uses it opens up.
If the file and the dialog are that closely related, why not let the dialog object open/close the file accordingly? Otherwise, leaving a file open for the duration of the application is an invitation for trouble.
b_girl wrote:
Is it best to maybe put that CFile object inside the Doc class?
It's certainly better than the frame's class. Whether it's "best" or not would depend on some other factors, which are unknown at this point.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
DavidCrow wrote:
why not let the dialog object open/close the file accordingly?
the dialog object does open/close the file whenever it needs to. the file doesn't stay open the whole time. i'm talking about just creating the file (with mode::Create). as of right now, the mainframe class creates the file but that's all it does. the rest of the operations on the file are carried out by the dialog object.
|
|
|
|
|
b_girl wrote:
i'm talking about just creating the file (with mode::Create).
Let the dialog object create the file, too.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
But the dialog object may be created/destroyed more than once... and i need that file to stay in-tact. the first time the dialog object is created, the file will be used for writing. the file needs to remain after the dialog object is destroyed, because every other time the dialog object is created the file will be used for reading.
|
|
|
|
|
b_girl wrote:
the file needs to remain after the dialog object is destroyed...
Files don't go away, unless they are explicitly deleted. The persistence of a disk file has nothing to do with whether an object (e.g., dialog) exists or not.
What is wrong with:
class CMyDialog : public CDialog
{
private:
CStdioFile file;
};
BOOL CMyDialog::OnInitDialog( void )
{
CDialog::OnInitDialog();
file.Open(_T("..."), CFile::modeCreate | CFile::modeNoTruncate | CFile::modeReadWrite);
or
int nMode = CFile::modeCreate | CFile::modeNoTruncate;
if (_access(_T("..."), 0) == 0)
nMode |= CFile::modeRead;
else
nMode |= CFile::modeWrite;
file.Open(_T("..."), nMode);
or
int nMode;
if (_access(_T("..."), 0) == 0)
nMode = CFile::modeRead;
else
nMode = CFile::modeCreate | CFile::modeWrite;
file.Open(_T("..."), nMode);
}
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
you know, maybe there's nothing wrong with that. i didn't realize you could combine modes like that.
i'm assuming this:
file.Open(_T("..."), CFile::modeCreate | CFile::modeNoTruncate | CFile::modeReadWrite);
will create the file if it hasn't been created, and allow it to be read/written...
like i said before (or i think i did at least), i'm somewhat new to programming for windows with vc++, so i don't completely know all the little tricks and such.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
