|
No. You simply cannot have what you want under Win32. The reason is simple. A DLL is loaded into each processes address space. Without that, a program couldn't access the DLL since it wouldn't exist in it's virtual space.
Under Win16, there was only one global address space, so DLL's were only loaded once. But in Win32, each program has it's own and DLL's can be relocated anywhere in the space if some code already exists at the preferred loading address.
That's why I suggested shared memory segments to share the common data.
|
|
|
|
|
Ok, I'm aware that it lacks in details, but that's what I have so far:
Someone here implemeted a skin mechanism for an application.
He uses a script and compiles it into a resource list.
I'm pretty sure he used bitmap streching for resizing.
The problem is this:
Resizible windows that he defines as Dialogs leave ugly background color marks when resizing them. This only happens on Win9x (Inferior GDI performance?). Windows that are defined as CWnd and not CDialog do not leave the color traces.
Any leads on where to start solving the color traces of the dialogs? How is Dialog resizing different from windows resizing?
Thank you, Any help would be great.
Ori
|
|
|
|
|
I need to add a script after a request of some asp files.
My solution: In the method OnURLMap if the physicalpath is filename.asp it creates a temporary file at the same directory called ~filename.asp and it changes physicalpath to this new file.
Why doens't it works?
Client's browser receive Errors 500 and 404 file not found.
Obs: New ~filename.asp is created and can be accessed by it's url.
|
|
|
|
|
Hey,
Does anyone know about a quality resource that would show me how to store and retrieve BLOBs (specifically, an image) to and from a database? (In MS-SQL Server 7/2000, using ODBC).
Thanks!
Oz
|
|
|
|
|
HI,
I want to pass class* as a parameter to DLL..
Without using MFC extension dll...
I mean as a regular dll..
I think when I correctly pass the address information of
Class*, I could call the method of it..
Is it difficult to understand??
See Next codes:
In exe :
1. declare Class CA (no inheritance..)
2. define all the methods of Class CA..
3. in some handler code,
CA* inexe = NULL;
Set(inexe);
inexe->aa();
inexe->bb();
In Dll :
1. declare and define export func Set() as follows:
void Set(CA* indll)
{
CA SI; //SI is instance of CA in DLL
indll = &SI;
}
2. then I can copy the address of CA instance in DLL..Right?
so now inexe has address of CA instance in DLL..
Is it correct??
One more thing that makes life horrible..
I'll declare and define of CA in exe that has different
implementation of CA's methods...
I mean, in dll aa() returns 10 but in exe aa() return 20...
Then I'll call methods of CA in dll...
But in reallity it won't work...
In exe, when I call the Set() with appropriate CA*,
the result of inexe()-> returns 20 not 10...why??
I think when using the address, I could access the
CA implementation in DLL..
But It just wouldn't work..
If anybody has a interest in this send me a mail...
Then I'll send you immedialtely complete sample DSW...
and other DSP and cpp..h...lib...exe....dll...OK??
So thanks for reading .... 
Regardz
-Ryan
|
|
|
|
|
There are a few things that you'd need to change to make it work the way that you intended it to work.
First of all, you need to change the Set function to take in a pointer to a pointer.
Secondly, in your set function you are creating a CA object on the stack (which will get destroyed as soon as the function returns, even though you may have copied the correct address - which doesn't happen anyway.
Try this...
In DLL:
Set(CA** ppCAInDll)
{
CA * pA = new CA;
*ppCAInDll = pA;
}
In EXE:
CA* inexe = NULL;
Set(&inexe);
inexe->aa();
inexe->bb();
Make sure you delete the object pointed to by inexe, since it's been new'ed in the dll.
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
