|
Thanks so much, Mark! I somehow missed the SB_ENDSCROLL code in the documentation, but I tried it, and it is exactly what I needed!
Thank you, thank you, thank you!
|
|
|
|
|
You're welcome, you're welcome, you're welcome!
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
|
|
|
|
|
I just upgraded my compiler from VS2003 to VS2005 SP1 and when I attempt to display
a modal dialog which is contained in a DLL, I get an assertion (in DEBUG only).
I have traced the problem to the following line of code :
#ifdef _DEBUG
if ( AfxGetApp()->IsKindOf( RUNTIME_CLASS( COleControlModule ) ) )
{
TRACE(traceAppMsg, 0, "Warning: Creating dialog from within a COleControlModule application is not a supported scenario.\n");
}
#endif
What I found is AfxGetApp() is returning NULL when I call it from my DLL, which causes the assertion in IsKindOf(...)
I also found that is is a "bug" with VS SP1.
Has anyone figured out how to make this call work.
BTW, I do make a call to "AFX_MANAGE_STATE(AfxGetStaticModuleState());" immediately after entering my DLL function.
Few other notes which might be of interest:
I am building MFC as a static lib (company requirement)
I am statically linking (not calling LoadLibrary) for the DLL
I skate to where the puck is going to be, not where it is. --Wayne Gretzky
|
|
|
|
|
Russell Gantman wrote: I am building MFC as a static lib
So you're linking the DLL to the static MFC library and linking the app to the static MFC library, right?
In that case, you can't pass any MFC class (or derived) objects between the app
and the DLL.
Also, you need to make sure you initialize MFC for the DLL, and follow the rules
described here: Regular DLLs Statically Linked to MFC[^]
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark Salsbery wrote: So you're linking the DLL to the static MFC library and linking the app to the static MFC library, right?
That is correct
Mark Salsbery wrote: In that case, you can't pass any MFC class (or derived) objects between the app
and the DLL.
I follow that rule also
Mark Salsbery wrote: Also, you need to make sure you initialize MFC for the DLL, and follow the rules
described here: Regular DLLs Statically Linked to MFC[^]
The DLL I am linking to is an MFC DLL (MFC app statically linking to MFC DLL), do I need to follow the same rules (deriving from a CWinApp) in this case?
I have a small project where I was able to reproduce the issue I would be willing to share
I skate to where the puck is going to be, not where it is.
Wayne Gretzky
|
|
|
|
|
Russell Gantman wrote: The DLL I am linking to is an MFC DLL (MFC app statically linking to MFC DLL), do I need to follow the same rules
Yes. There's no such thing as statically linking to a DLL.
DLLs are always linked dynamically, at runtime, so the same rules apply whether you use
early binding (ie an import library) or late binding (ie LoadLibrary()) to link an app to a DLL.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark Salsbery wrote: DLLs are always linked dynamically, at runtime, so the same rules apply whether you use
early binding (ie an import library) or late binding (ie LoadLibrary()) to link an app to a DLL.
I am doing early binding.
Could my problem be that I do not have a class which is derived from CWinApp?
I have a normal C++ class (as an interface to my exe) which then displaysthe dialog...
Here are the class declarations
As I stated before, this worked without a problem in VS2003, it just when I went to VS2005, I saw this problem
Here are the definition for the classes in my DLL
This class is the interface between my application and my dialogs:
<br />
#ifdef _DLGPWENTRY_<br />
#define CLASSSTATE __declspec(dllexport)<br />
#else<br />
#define CLASSSTATE __declspec(dllimport)<br />
#endif<br />
<br />
class CLASSSTATE CPasswordPrompt<br />
{<br />
public:<br />
CPasswordPrompt();<br />
bool showDialog( int &lDialogReturn );<br />
};<br />
The dialog class (which is contained in the same DLL as the above class) is defined as follows:
<br />
class CPasswordPromptDlg : public CDialog<br />
{<br />
DECLARE_DYNAMIC(CPasswordPromptDlg)<br />
<br />
public:<br />
CPasswordPromptDlg(CWnd* pParent = NULL);
virtual ~CPasswordPromptDlg();<br />
<br />
enum { IDD = IDD_PWPROMPT };<br />
<br />
protected:<br />
virtual void DoDataExchange(CDataExchange* pDX);
<br />
DECLARE_MESSAGE_MAP()<br />
};<br />
From my main app (exe) I instantiate a CPasswordPrompt class and call showDialog()
It is in CPasswordPrompt::showDialog() where I instantiate my dialog class and call the
DoModal() after a call to: AFX_MANAGE_STATE(AfxGetStaticModuleState())
This is done to abstract the GUI work from the rest of execution,
now I can change how my GUIs are drawn by replacing the DLL and my code does not change.
Thank you for your help.
I skate to where the puck is going to be, not where it is.
Wayne Gretzky
|
|
|
|
|
Russell Gantman wrote: Could my problem be that I do not have a class which is derived from CWinApp?
Yes, definitely and most likely 
Since the DLL's UI is completely independent of the EXE's UI, there needs
to be a CWinApp object in the DLL.
Also note that since there's no message loop in the DLL, you need to
forward messages from the EXE's message loop as described in the docs
(linked to previously).
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark Salsbery wrote: Russell Gantman wrote:
Could my problem be that I do not have a class which is derived from CWinApp?
Yes, definitely and most likely
Thanks a lot for your help, that did it.
All I had to do was add another class derived from CWinApp and instantiate an object of that type and the assertion
went away. It really makes sense since there was no CWinApp object which means AfxGetApp has nothing to get
I skate to where the puck is going to be, not where it is.
Wayne Gretzky
|
|
|
|
|
Have any one of you migrate any VC++ (using MFC, ver 6.0) program from Windows 32 bit operating systems (XP, 2000, ME, 98SE) to Windows Vista? If so, can you please share some of the problems you have faced and there resolutions? (I heard that Vista has a memory issue if somebody uses malloc/calloc functions). Any additions to this list (with/without resolution)?
|
|
|
|
|
kchatterjee wrote: (I heard that Vista has a memory issue if somebody uses malloc/calloc functions).
Imagine all of the programs that would cease to function if that were true.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
He probablz refers to this:
Windows Vista restricts non-Win32 apps to 32 MB of memory.[^]
That *is* a Problem for many a program.
Thats a simple try to kick out other compilers than Microsofts. Microsoft is increasingly locking us in.
Though I speak with the tongues of men and of angels, and have not money, I am become as a sounding brass, or a tinkling cymbal.
George Orwell, "Keep the Aspidistra Flying", Opening words
|
|
|
|
|
I need to use threads in my project,
the best thread library is posix, or another thread library?
thanks
|
|
|
|
|
why do you need to use a thread library?
---
Yours Truly, The One and Only!
devmentor.org
Design, Code, Test, Debug
|
|
|
|
|
i need to make multithread application, that is why i am wondering that which thread class is better, normal window thread library(AfxBeginThread), or posix?
|
|
|
|
|
Use Windows threading if you're developing for Win32.
If you're going to use the C runtime library use the _beginthreadex( ) instead of CreateThread( )
If you're developing a MFC, then use the MFC thread APIs like AfxBeginThread( )
---
Yours Truly, The One and Only!
devmentor.org
Design, Code, Test, Debug
|
|
|
|
|
Look at boost::threads[^], a portable abstraction of the threads as offered by the platform.
Though I speak with the tongues of men and of angels, and have not money, I am become as a sounding brass, or a tinkling cymbal.
George Orwell, "Keep the Aspidistra Flying", Opening words
|
|
|
|
|
|
Gofur Halmuratov wrote: or another thread library?
I would use either TBB mentioned above, or use Qt. The primary reason is that most threading libraries lack thread compatible containers for data. TBB will be easier to code since it is higher level than most thread classes, but it still amounts to the same thing: you insert the code into a skeleton codeset. If you are simply using threads for scientific problem solving you may not need the storage containers, still it is nice to have.
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
|
That's more than a little vague - or a bunch of questions.
The open other applications for example...
Do you mean bring running applications to the foreground?
Do you mean run new programs? If so, read up on ShellExecute, or CreateProcess.
How will this be presented to the user?
A few buttons on a dialog that run hard coded programs?
Read a list of programs from shortcuts in a directory?
An editable list?
Will you extract the appropriate Icon from the executable so you can show a pretty pic to the user?
As you can see, this is multiple tasks. If you can more clearly define them, you may get help with individual ones. At the moment it looks like: "I have to write something, and I'm not even sure what it needs to do. Can you do it for me?". And that's a rapid road to being ignored.
You've asked many questions here on quite complex subjects, and even answered some. So none of the above should stretch you too far.
Good luck!
Iain.
|
|
|
|
|
Iain Clarke wrote: Do you mean run new programs? If so, read up on ShellExecute, or CreateProcess.
No
Iain Clarke wrote: Do you mean bring running applications to the foreground?
See the thing is ... lets take Control panel as an example. It has a number of program right. So when you click on any one of them, the open a specific application. Something like that.
Iain Clarke wrote: How will this be presented to the user?
I have seen this before and it looks like a SDI window with a white background and there is a number of icons within it and click on any of the icons will open the application.
Iain Clarke wrote: Read a list of programs from shortcuts in a directory?
Something like that ...
Does this help ??
Thanks for the response
Regards,
The only programmers that are better that C programmers are those who code in 1's and 0's ![Green Alien | [Alien]](https://codeproject.freetls.fastly.net/script/Forums/Images/alien.gif)
 Programm3r
My Blog: ^_^
|
|
|
|
|
OK, so what's stopping you?
Using MFC, you can make an SDI application, and make the view descend from a CListCtrlView. Set it to large icon view, and you're part of the way there.
Choosing the text / icons is another challenge. Pick a directory, and use FindFirstFile etc to get all the *.exe files there? Extract the icons from each of them?
Then handle the double click / enter events to say "aha, the user has chosen one!". Then launch the application. As you say you don't want to a run a program, then I don't know what you mean by it. But I'm sure it's explainable.
Basically, just break this down into smaller parts.
First, the listview SDI app, and fill it with a couple of hardwired words / icons.
Second, get a list of the programs / thingies you care about.
Third, give them appropriate pics.
Fourth, work out how to handle enter key / double clicking on one.
Lastly, lauch the application the use picked.
Iain.
|
|
|
|
|
|
Better u use the List Control for that. That will give u a look like Desktop. And Simple use the Createprocess to create the Open the Application u want.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
