C / C++ / MFC

8-Mar-09 23:58

--- Warning! What I talking about here is pure Borland C++ and I don't want to use any MFC!!! ---

Hi!

I've found an article about how to make a custom control as a dll. I have made custom controls before, but not as dlls. So when I tryed to do this I came across the following problem:

If one want to load a dll in different apps, it will probably mess up the data it have. This is becouse It implemented as a class that have it's own data and functions.

So how to make a control nicely? Should I make a lib from the class, a dll and have only one instance or just write the functions in C style in to the dll - but in this case, how I manage the data?

What I thinking of as an example is a simple 2-state button control which have its own bool to indicate the state. This can have as many instances as want and also in different apps at the same time. In Windows it's in a dll...

My problem was while trying to implement this the message handle. A control is a window havin' it's own message handle procedure what - as far as I know it - can't be in a class but only in global. So when I load the dll in defferent apps, and make different instances of the class in it, which ones functions will it call??? Big Grin | :-D

Okay, these are the basic problems I have and only want to know how to implement that kind of button as in the example. So opinions and solutions are welcome.

Nishad S9-Mar-09 1:07

Re: How to make a custom control nicely? [modified]

9-Mar-09 1:07

I think you can create DLL for custom controls. I am not sure about creating OCXs in Borland C++.

AFAIK, its better to create a class hierarchy to create custom controls from WIN32 SDK.
Like
class WndBase;
class BtnWnd : WndBase;
etc.

AFAIK, it is better to pass the "this" along with CreateWindow as lParam. Then you will get it in WM_CREATE (from lParam pointing to CREATESTRUCT). There you can

And you can use SetWindowLong with GWL_USERDATA to store the "this" to each window, so that you can link to the class functions (using GetWindowLong) when WindowProc is executed.

You can write virtual functions in the BaseClass for handling messages and in the derived class (BtnWnd) you can override them for using.

Hope my suggestions will be useful for you of some kind... Smile | :)

- ns ami -

Igen19-Mar-09 1:31

9-Mar-09 1:31

Thank You!

I'll try to check the thing you've sad, but I'm not sure you speaking of a multiple instance dll or a static lib. Smile | :)

Just kidding...

Yes I know I have perversions in programming, but this is why evryone likes my work... Big Grin | :-D

But I feel on bottom now, becouse I find a code doing something like this and just can't understand it. Sigh | :sigh:

This is the link: http://www.efgh.com/software/pbutton.htm[^] and there can be found the source.

He use a struct called PICTUREBUTTON and initalize it in the message handler like this:

<br />
  PICTUREBUTTON far *p;<br />
  HGLOBAL hp = (HGLOBAL) GetWindowHandle(handle, 0);<br />
  if (hp != NULL)<br />
    p = (PICTUREBUTTON far *) GlobalLock(hp);<br />

I'm not sure how will this be permanent and also I just can't understand the jibberish about messages what the picturbutton send to it's parent... Confused | :confused:

Edit: OK maybe I can make a use of the answer, but the instance is always know itself, but how could the parent know about the window??? In the example I just load the dll and it calls registerclass when DLL_PROCESS_ATTACH and that is it! So how to get the window handle for/from the parent?

modified on Monday, March 9, 2009 7:59 AM

Nishad S9-Mar-09 2:10

9-Mar-09 2:10

Igen1 wrote:
a multiple instance dll or a static lib

I didnt get you.

Igen1 wrote:
I have perversions in programming, but this is why evryone likes my work...

Igen1 wrote:
HGLOBAL hp = (HGLOBAL) GetWindowHandle(handle, 0);

I am not sure about this function.

Igen1 wrote:
I'm not sure how will this be permanent

I think they are doing the same mechanism that I suggest. But instead of keeping the data (here it is a structure, instead of class that I suggest) in the window's user data, they are keeping it in global memory.

- ns ami -

Nishad S9-Mar-09 2:17

9-Mar-09 2:17

Igen1 wrote:
Edit: OK maybe I can make a use of the answer, but the instance is always know itself, but how could the parent know about the window??? In the example I just load the dll and it calls registerclass when DLL_PROCESS_ATTACH and that is it! So how to get the window handle for/from the parent?

You edited after my reply... Smile | :)

Igen1 wrote:
So how to get the window handle for/from the parent?

You should have the export class for you control. That is advisable. So you can call the your own function named Create( HWND parent, .... ) or something like that.

- ns ami -

Igen19-Mar-09 3:02

9-Mar-09 3:02

ns ami wrote:
You edited after my reply... Smile

lol Sorry I didn't see it at the time...

I don't know this export class thing you say, but I rhink it's a greater problem now that I can't call any of my functions in the class and whats more? I can't even compile the testapp becouse it can't find the constructor and destructor... The problem is with the calling. __stdcall and extern "C" is the answer I know, but not with classes becouse it uses C++ no metter what I try.

Nishad S9-Mar-09 3:20

9-Mar-09 3:20

Igen1 wrote:
I don't know this export class thing you say

OK... so I think reading something like this[^] will be useful for you.

- ns ami -

Igen19-Mar-09 4:00

9-Mar-09 4:00

Sorry, I know it seems like I'm an amatuer, but it's becouse of the good for nothing tutorials around the net. I've made dlls before, but mostly in MFC. I just fed up with Visual C++ and started to learn everything in native Windows. But this was about 8 years ago so don't think I never read somthing like "that". But these are just don't working or don't give answers to things like the unresolved externals becouse of the nameing c++ uses...

I tell you onece more to be clear. I have a problem that when exporting my class it uses c++ nameing so the functions can't be find under the specified name becouse it renames them - it add something unmeanful string to it. And this isn't changes even if i'm using exter "C" or __stdcall or even I use compiler/linker options to use Standard Call. Now answer this. VC++ never complaind about things like this but Borland c++ just doing things like this and there isn't any topic that says if you encounter this kind of problem then do the following and everything will be allright. So this is a problem and with the first question I was asking some opinion which one is better lib or dll and if dll than how to use the message handler and the class in several instances. But this isn't getting clear reading beginner tutorials and advanced tutorials are not available in the topic exept the one I posted but you don't even know how it works with me. Big Grin | :-D

now that is the sum.

I'll read a lot and post an article with this topic with no VC++ and MFC in it...

Stephen Hewitt9-Mar-09 3:04

Stephen Hewitt

9-Mar-09 3:04

Igen1 wrote:
If one want to load a dll in different apps, it will probably mess up the data it have. This is becouse It implemented as a class that have it's own data and functions.

Control instance-specific data would be loaded on the heap and hence it's a non-issue if it's packaged as a DLL or not.

Steve

Igen19-Mar-09 4:04

9-Mar-09 4:04

So you saying that if I load the dll for another app it will be another entry in heap for the variables in the class (or globals too)?

Then what if I want several of the control in one app - on eno dialog? My problem is the message handler here. So it will use the same code, but with the current instances variables if I'm understanding clearly.