|
Hi, really thanks for your response....
Unfortunately, it just wouldn't work..
I think the same idea like you...I have to pass the
address of class's intance...I mean I should pass the
address of pointer to class's instance in DLL..
Anyway, the result of aa() is that of the implementation
in exe..not in DLL..
As far as I know about the class memory allocation modeling,
the pointer of class should point the instance's top..
In this case, (no member variable, 4 member functions)
it should point the constructor(first method)'s address..
So I think that if I could point out the proper address
of class, I can point the proper binary implementation...
But, as a result....I was wrong..
I want to find this out what the hell is going on in dll..
And about the class memory allocation...
If you have some interest about this..Let's dig it out!!
Give me your e-mail...I'll send you the whole codes I have..
If not...Thank you very much for suggestion..
And later I'll let you know the result of my study..
Regardz
-Ryan
-p.s The former responser's idea is wonderful..
I theaded also his idea..
Checking it out will be helpful too...
|
|
|
|
|
I don't really have a lot of experience in this field, but I think using a second set of dll's for the different classes (one for each class you want to use) should do the job (passing the current class-dll-name to your dll, which dynamically loads it). Exporting classes form dll's is documented in some postings on codeguru and codeproject).
Wolfgang
|
|
|
|
|
I think that there is a fundamental concept that must be understood. A regular dll (a dll that is not a MFC extension dll) can be called by programs compiled by any compiler capable of calling DLLs. That is, your dll is compatible with Visual Basic and many other development facilities. Most of them do not know what a C++ class is, so it is unlikely (impossible?) for you to be able to have a class as a parameter.
I that a couple of possibilities are:
(1) make an MFC extension dll that can be called by your MFC programs and a second dll that is a regular dll that calls the first dll and that can be called by non-MFC programs
(2) create an (ActiveX) Automation interface, which (I think) can be implemented as either a dll or an exe.
A third possibility might be that you write an MFC extension dll and a separate exe that provides an Automation interface and that calls the extension dll.
|
|
|
|
|
Hi, Thanks for your response..
A regular dll..and not MFC extension dll..
As I found a minute ago in MSDN,
the regular dll has 3 types..
1. Non-MFC DLLs
2. Regular DLLs statically linked to MFC
3. Regular DLLs dynamically linked to MFC
I used #3 type...And what you point out is #1 type..
Hm....
Well, you are right in your point..Sorry for I didn't state
the exact information about situation...
In #3 type, I can use classes in DLL and can not export the
class and all other members of it..Am I correct??
But I can't convince that I can export class* as a parameter
Anyone know about this....??
And about your suggestion on possibilities:
(1)DLL in DLL...
I wonder if an exe can't access the dll's exports, neither
it is with regular dll...
And I have no compile error and link error with #3 type,
I would not think about this...
(2) Use Automation Interface....
Using COM...well I think I could make this dll as COM server
But what is with the Automation??..Need your teaching...
And my target is polymorphism of method's implementaion..
I'll separate implementation of class's method in exe and
in dll so that I can use proper method of it...
I know this is not the purpose of dll and c++..
If I need polymorpism, I can use virtual keyword..
But this is not good for reuse, as you can read in Essentil COM #1, for the real reuse of codes..
The source level reuse of legacy code is not effective..
And I'm tired to work on registrys....Huh...
So for simple functionality I'll use this way rather than COM and ATL..
This is some copycat of COM..
Until the unveil of C# and .NET, I don't want to implement
COM server..I'll just use components the others have done..
In .NET and CLR, COM is just a file...no registry needs..
Huh...
Anyway thanks for your response...
Regardz
-Ryan
-p.s Read the other thead of my question..
Mr. Jignesh made a good response...Check it out..
|
|
|
|
|
Hi Ryan,
I think you get 20 because, when you compile the exe, the compiler knows its implementation of CA, so it calls its functions. The compiler has no mean to distinguish between a CA object created in your exe and one created in the dll.
An object contains only data members and virtual tables, the member functions are just like any other global function, but they are passed this as the first parameter: this is how they can actually access object's data.
When you use a CA object constructed in the dll, you get its binary data but not its member functions.
And I think you may have unpredictable run-time errors if their internal data format is not the same.
I don't know how you can solve this
Cheers,
Paolo
|
|
|
|
|
a) If you want two implementations of the same interface, you need to use virtual functions. Make a base class that has your interface, and then derive two classes from it - one that returns 10, and one that returns 20.
Then objects of your class will have a virtual method table (pointer at the beginning of the object's data) that points to a list of function pointers, that's how you can get a different function to be called. The first responder had the right idea RE: returning a pointer to a pointer.
b) Just make sure that the EXE and the DLL both include the header file that defines the interface, and they will work with each other.
c) DLLs can be C++ specific, they don't -have- to be compatibile with Visual Basic or any other language.
|
|
|
|
|
For MFC programmers, an important distinction is whether a DLL is an MFC Extension DLL or not. It is certainly true that a regular DLL can be C++ specific to the extent of being incompatible with other languages such as Visual Basic, but what is important is that MFC classes can be shared between EXEs and DLLs only when the DLL is an MFC Extension DLL. See MFC "TN011: Using MFC as Part of a DLL" and "TN033: DLL Version of MFC".
|
|
|
|
|
Howdy Folks!
Is there a way to redirect my dialog to get its own system colors somewhere else in the registry? I know how to write the colors into the registry, but I want to know if there is a way to make my application only to look for the registry colors elsewhere.
I would also like to know how to change the color of the Menu in my MFC application, I have tried to add code to my OnDrawItem when its called by the Menu, but I don't know if I use the right commands (I'm no ACE at C++ so far, hehe, learning fast though)
Another "thingie", hmm... I have set my dialogs background with the SetDialogBkColor() but it seems like the (what do you call it, hmm... border, frame, nm) the outer edge of the window is still taking the colors from the system. How do I paint that area?
Then there's the problem with my controls. I have a Slider that still takes the system color in it's "slider-path" and on the "slider-knob" (or whatever you call these, hehe). Where can I set those colors?
Then theres my ComboBox wich has that little arrow, (you know, the one you klick on to bring down the ComboBox's menu) I want to set its color too =)
If you happen to know how I can "redirect-the-registry-thingie" there's no hurry for the rest of the answers, but I'd like to know the other ways to do it too =)
Thats all Folks, thanks for redin'!
/Fredrik
|
|
|
|
|
Before you go messing around with color in your dialog box, you should go to this web page:
http://www.iarchitect.com/mshame.htm
It talks about all of the evils of user-interface design.
Sure, you can setup your own registry keys for colors, but at that point, they are no longer considered "system" colors.
In order to paint the 3-d portions of your dialogs, you'll probably have to override the OnPaint() function and do *all* the drawing yourself.
As far as painting controls, the same thing applies, only you'll have to subclass the controls and override their OnPaint code too. Don't forget to make them owner-drawn in your dialogs too.
Are you sure all of this is worth the effort?
If you want to make your dialogs look more vibrant with less work, use Visual Basic...
|
|
|
|
|
Hi again!
Thanks for the info John, and the site you gave me was good. I do need to change the colors though, even though it's sort of against my will, hehe. How do I direct the registry so that I can make my application get its own colors (true that they wouldn't be "system" colors no more, like you said, good point). I want the colors of the other applications running to still use the real system colors, and only my application to use the "fake" or call them "virtual" system colors. =)
I would guess that this way would be the best since it would give me a better view of the colors than to override OnPaint code for all the controls.
Thanks again,
/Fredrik
|
|
|
|
|
I'd probably setup registry keys (as strings) that contained the three color values used to instantiate a CCOLORREF value.
DlgBkgrnd="0,0,0"
DlgButtonFace="1,1,1"
etc...
I would also probably set these up under the HKEY_CURRENT_USER key if you anticipate more than one user using the software on a given machine. This way, each user's settings will be unique to that user (when they log on to the machine).
I believe there's a couple of registry classes here on Code Project.
|
|
|
|
|
Hi!
I know how to do what you just described, but what I need to know is how to override the system colors for my dialog window only. I have no clue how to make my application to actually look for the colors elsewhere than at the place where windows has it's system colors. I know how to create the keys and set upp the palette values I need in my dialog, but when I have made my own palette in the registry, I have no clue how to make the dialog to actually be pointed to my own defined palette in the registry rather than the one it is pointing at by default (the system colors).
Thanks a bunch,
/Fredrik
|
|
|
|
|
IS there a way to lauch an console EXE using ShellExecute or another API that will allow the output to be piped to a control CEditCtrl or CListCtrl?
|
|
|
|
|
See: http://msdn.microsoft.com/library/psdk/winbase/prothred_4uus.htm
I think that the CodeGuru web site has an example and probably this web site does too but I have not looked around in this web site much yet.
|
|
|
|
|
How do you change the foreground color of a button?
|
|
|
|
|
I am far from good at C++ but this is what I did after looking around on diffrnt sites, hope it helps/works =)
First: I used MFC to make the button in my dialog, then I chose Properties with left mouse button on the button and set the button to ownerdrawn. Then use Classwizard to add the WM_DrawItem (Is it called a listener? Nm...hehe) to your dialog window. Then add the following code, with a few changes:
void CAboutDlg::OnDrawItem(int nIDCtl, LPDRAWITEMSTRUCT lpdis) // (Change the name CAbotDlg to your Dialogs name (Classwizar should do this for you though))
{
CBrush myBrush;
CBrush m_brHollow;
myBrush.CreateSolidBrush(RGB(178,196,213)); //Change the RGB color to what you want the color of the the button to be
m_brHollow.CreateStockObject(NULL_BRUSH);
const UINT& nAction = lpdis->itemAction;
// Full redraw or selected (up/down) state changed
CWnd* pCtl = CWnd::FromHandle(lpdis->hwndItem);
CString sText;
pCtl->GetWindowText(sText); // button text
CRect rc;
pCtl->GetWindowRect(&rc); // window rectangle..
pCtl->ScreenToClient(&rc); // ..client rectangle
if (lpdis->itemState & ODS_SELECTED) // button is down:
rc += CPoint(1,1); // shift southeast
CDC* pDC = CDC::FromHandle(lpdis->hDC);
// painting the background
CBrush* pOldBrush = pDC->SelectObject(&myBrush);
pDC->PatBlt(0, 0, rc.Width(), rc.Height(), PATCOPY);
pOldBrush = pDC->SelectObject(pOldBrush);
if (lpdis->CtlType==ODT_BUTTON)
{
// Draw button border using COLOR_BTNTEXT
CBrush* pOldBrush = pDC->SelectObject(&m_brHollow);
CPen pen(PS_SOLID, 2, GetSysColor(COLOR_BTNTEXT));
CPen* pOldPen = pDC->SelectObject(&pen);
pDC->Rectangle(&rc); // Draw rectangle
// Draw button text
pDC->SetTextColor(GetSysColor(COLOR_BTNTEXT));
pDC->DrawText(sText,&rc,DT_CENTER|DT_VCENTER|DT_SINGLELINE);
pDC->SelectObject(pOldBrush);
pDC->SelectObject(pOldPen);
} else {
// Note: assumes static icon!
pDC->DrawIcon(0, 0, AfxGetApp()->LoadIcon(IDR_MAINFRAME)); //I'll be honest to tell you I don't fully know what this line does =)
}
}
Hope that helps, I'll be checking in here later for questions/remarks etc...
/Fredrik
|
|
|
|
|
Thanks for the help, I had gotten a solution similar to this from another site, nice to know we all think alike. I am actually going to use the colorbtn class that is posted on here under the button control on the front page for this site. Seems like the easiest way to go. I appreciate your help, let me know if you ever need anything.
|
|
|
|
|
Visual C++ 6.0
MFC
Does anyone have any code for putting a bitmap into a status bar pane?
Many thanks in advance.
|
|
|
|
|
I want to create an exe file from another exe file.
There is one exe file, which when run, creates another exe
file. The first exe file remains intact. How this could
be done?
Can anybody help me in this regard?
Thanks
|
|
|
|
|
The Win32 Command to spawn another exe is CreateProcess(...). This will start another EXE and leave the first EXE running. is this what you are looking for?
|
|
|
|
|
Any methods to get the coordinates (upper left, bottom right) of the AppBar? I want to use it to resize other windows.
Thanks all!
|
|
|
|
|
If you mean the Taskbar, then call SHAppBarMessage() with the message ABM_GETTASKBARPOS.
It sounds like you want to know the area of the desktop not covered by the Taskbar and other app bars. If that's so, then just call SystemParametersInfo(SPI_GETWORKAREA).
|
|
|
|
|
Hi there,
I tried this site to access the mail object form
the outlook from my
VC ++ using the script control.
But it is giving some error.
The code is ***
#import "C:\Program Files\Microsoft Script Control
\msscript.ocx"
using namespace MSScriptControl;
IScriptControlPtr
spScriptCtl(__uuidof(ScriptControl));
spScriptCtl->put_Language(bstrLanguage);
spScriptCtl->AddCode("Sub Test1\nSet myOlApp ="
"CreateObject\"Outlook.Application\"\n"
"MsgBox \"Hello World\"\n"
"Set nsMAPI = myOlApp.GetNameSpace\"MAPI\"\n"
"Set objInbox = nsMAPI.GetDefaultFolder\"6\"\n"
"i = 1\n"
"While i <= objInbox.Items.Count\n"
"Set objMail = objInbox.Items\" i \"\n"
"If objMail = \"Gimme ur contac........\" Then\n"
"MsgBox \"Hello World Before\"\n"
"End If\n"
"i = i + 1\n"
"Wend \nEnd Sub");
spScriptCtl->ExecuteStatement("Test1");
Sub MSOff()
'DESCRIPTION: A description was not provided.
'TODO: Put macro code here
'Create the Session Object
Set myOlApp = CreateObject("Outlook.Application")
Set nsMAPI = myOlApp.GetNameSpace("MAPI")
Set objInbox = nsMAPI.GetDefaultFolder(6)
i = 1
While i <= objInbox.Items.Count
Set objMail = objInbox.Items(i)
' check the name of the letter
If objMail = "RE: CST13598207ID - help" Then
' do stuff with objMail (like access contents) -
' see Outlook documentation for things you can
do...
End If
i = i + 1
Wend
End Sub
It is not showing error while icomiling.But it is
not even executing the "Test" method.The reason
why i telling is it is nit showing the Message Box
"Hello World Before". So what may be the reason
for not executing the Test method script.
Another problem is in the line
nsMAPI.GetDefaultFolder(6) .But in the macro i
write it as nsMAPI.GetDefaultFolder\"6\"\n". ANd
how can i write nsMAPI.GetDefaultFolder(6) there.I
want to get the message body if the message
matches the same.
Please help me out
Expecting your reply
Reny
|
|
|
|
|
Hi,
I have to upgrade a tool developed by VC++ ver1.52 (16 bit) to VC++ ver6.0 (32bit).
1. Is there any special care that needs to be taken ?
2. Is there a tool to help me in doing this.
thank you in advance
|
|
|
|
|
Is this an MFC program or a Windows SDK program?
For help with SDK programs, there is a program called PortTool.exe. It will walk through a source code file and tell you of things that need to be changed. I don't know where this tool comes from. Check MSDN to find it.
In my experience, vanilla MFC apps port fairly easily, though there are some minor changes to your source code (some commenting of code will get you there).
For SDK apps, there is a lot more work involved. One place that needs to change is that the WndProc parameters (WPARAM and LPARAM) change meaning. This means that you have to change your switch statements. This is also documented on MSDN.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
