Custom controls

[mark smit]

Hello,


I have been having problems with custom controls. I dont know how
to put multiple custom controls of the same type on my dialog without
haveing them all share the same internal variables. Are there some
flags that can be set so that each control has its own variable
space?




------------------
Cheers

[Michael Mattias]

Huh? When you define the control ID on a dialog, YOU decide its identifier; when you receive a callback, you know the ID of the control, and can use data accordingly.

If you mean, "what might be a cool way to store state-type information about each control on a dialog?" you can always use an array of UDTs.

I guess I just don't understand our problem; can you post an example?

MCM

[Chris Boss]

Mark;

Custom controls "should NOT" use Global variables !

The proper way to write a custom control is to use the

wndclass.cbWndExtra

member of the wndclass structure to define "extra" bytes of data
"unique" to each instance of your custom control, when Registering
your Window class. You need four bytes for every Long you store.

Then you use SetWindowLong and GetWindowLong to read and write data
from your Custom controls "extra" data bytes . Using this technique
you can store as many Longs as you need.

If you need to store data that is variable length in size, like strings
then you store handles to the Global Heap in Windows in the Long
storage in your window. You are then using Windows to store your data
by storing it in the Global heap, rather than in Global variables.

Note: See Third Party forum for my thread about a Custom control
Developer Kit I am working on (which handles all this for you). The
core routines were already used for my first custom control , a
Turtle Graphic control.

If you want' "advanced" information about writing custom controls
in DLLs (rather than ActiveX), get the following book :

Windows Custom Controls
by William Smith and Robert Ward
published by R & D Publications, Inc. , USA

The book was written for Windows 3.1, but most of the basic
concepts have not changed. There are few (if any) books on the
subject. This is the only book I could find, by searching the web.

It does a very good job of explaining the basics and the code is
easy to convert from C to PB (since it is generic C).




------------------

[Paul Noble]

Another way is to use the GetProp() and SetProp() API calls, to have Windows store user-named properties against a handle value. For example -

SetProp hWnd, "BITMAP", LoadBitmap( wParam, byval lParam )
...

if GetProp( hWnd, "PRESSED" ) = 1 then 
...

You have to release them at the end of your window procedure -

case %WM_DESTROY
  RemoveProp hWnd, "BITMAP"
  RemoveProp hWnd, "PRESSED" 
...

Just another idea.

Paul




[This message has been edited by Paul Noble (edited October 26, 2000).]

[Steve Hutchesson]

Mark,

Glad you are getting into the fun stuff. Custom controls can be very
useful if you have the need to do custom interfaces.

As Chris mentioned, you use the,

tbc.cbWndExtra = 40 ' 40 is MAX amount

member of the WNDCLASSEX structure as the location of the settings for
each instance of a window as this memory is local to each instance. After
creating the window, you use the following API to write the values to that
memory remembering that you must specify the BYTE offset for each section
you use.

SetWindowLong hndl&,0, ccb.bAlgn
SetWindowLong hndl&,4, ccb.hFont
SetWindowLong hndl&,8, ccb.colrU
SetWindowLong hndl&,12,ccb.colrD

Then you use GetWindowLong() to retrieve any of the values you need from
each location in the message handling code for the control that you
create.

It looks a bit messy but its no big deal and you can run as many instances
of the control as you like once you have it going and each instance will
store its own values independently.

Regards & Good luck with the controls.

[email protected]



------------------

[mark smit]

Thank you all so much!

I was at my girl friends hoouse last night so I brought my Petzold
book along and came to the same conclusion... "cbWndExtra" but there
wasn't much on the topic other than that. I think i'll be spending
some time with MSDN today.




------------------
Cheers

[Chris Boss]

Using the extra bytes for a Window (structure) will only allow
you to save a few Longs. You may need "larger" amounts of data
stored which requires using the Windows Global Heap.


There are four API functions you need to use to do this:

GlobalFree

GlobalAlloc

GlobalLock

GlobalUnlock

GlobalAlloc returns a handle to the memory block that windows creates
for you. This handle should be stored in one of the those extra
window bytes (as a long taking up 4 bytes). GlobalLock is used when
you want to access the data. GlobalUnlock is used to indicate you
don't need to access it anymore. GlobalFree will free (destroy) the
memory block when the control is destroyed.

You should create a memory block in the Global heap during the
WM_CREATE message of the custom control. You should Free (destroy) the
memory block in the Global heap during the WM_DESTROY message of the
custom control.

Using this technique you can store huge amounts of data unique to
each window (custom control) and your control won't require any
Globals for storing Window Unique data.




------------------

[Chris Boss]

Mark;

If you want to learn how to write custom controls correctly,
I strongly suggest you buy the book I mentioned above in a
previous post.

Windows Custom Controls

Generic Windows programming books don't discuss this subject indepth.
This whole book is on one subject and that is creating custom
controls.



------------------

[jcfuller]

Chris,
Does the book Windows Custom Controls deal mainly with 16bit?
The reason I ask is the Memory functions you list are the old 16bit
memory allocation calls.

James



------------------

[Chris Boss]

James;

While the book is dealing with 16 bit Windows, the
Global heap functions also existing in WIN32 (WIN95/98/NT) !

They are not obsolete. There is NO indication in the API docs
(WIN32API help file from PB) indicating they are obsolete.

WIN32 also has an alternate set of functions which are
exactly the same, but start with the word Virtual, rather than
Global.

These functions access Virtual memory (which can be swapped in
and out of RAM from disk) rather than the Global heap. It makes no
sense to use the Virtual functions for storing window data, since
it is likely small in size and likely needs to be accessed quite
often.


------------------

[Tom Hanlin]

Microsoft doesn't update the Win32 help file any more, so it's a bit
dated. The best resource for current information is MSDN.

GlobalAlloc is not obsolete, but VirtualAlloc is recommended for
performance reasons.

------------------
Tom Hanlin
PowerBASIC Staff

[Semen Matusovski]

From MSDN

Comparing Memory Allocation Methods
This topic provides a brief comparison of the following memory allocation methods:

CoTaskMemAlloc
GlobalAlloc
HeapAlloc
LocalAlloc
malloc
new
VirtualAlloc
The following functions are equivalent: GlobalAlloc, LocalAlloc, and HeapAlloc with the handle returned by the GetProcessHeap function.

The VirtualAlloc function allows you to specify additional options for memory allocation. However, its allocations use a page granularity, so using VirtualAlloc can result in higher memory usage.

The malloc function has the disadvantage of being run-time dependent. The new operator has the disadvantage of being compiler dependant and language dependant.

The CoTaskMemAlloc function has the advantage of working well in either C, C++, or Visual Basic. It is also the only way to share memory in a COM-based application, since MIDL uses CoTaskMemAlloc and CoTaskMemFree to marshal memory

------------------
E-MAIL: [email protected]

[Steve Hutchesson]

I am not sure what the importance is of the range of suggestions in
relation to memory for use with a custom control. The 40 bytes of extra
memory that can be associated with any instance of a created window can be
used in whatever manner the programmer chooses.

If there is a need for a pointer to allocated memory, this is of course
the place to do it. The older GlobalAlloc() family of functions will do
the job fine, VirtualAlloc() family functions are later and allocate a bit
faster and the CoTaskMemAlloc() functions are also very fast but I get the
idea that pursuing the performance increases in allocation speed for extra
memory associated with a window is like fitting a shopping trolley with
twin superchargers to get around the supermarket a bit faster.

I did like the suggestion by Paul Noble using the property functions as it
looks like another convenient method of associating instance specific data
to a window. My only comment is that the property removal should be done
in the WM_CLOSE message processing rather than the WM_DESTROY message as
there may be a memory leak if the removal occurs after the window has been
destroyed.

For Mark, the 40 bytes of extra memory that you can allocate with each
instance of a window is sequential and it requires the two functions I
mentioned earlier to write to and read from this memory,

SetWindowLong()
GetWindowLong()

They both address this memory from a zero based offset so that the second
parameter locates the part of the memory where the data is stored. Offset
0 is the first 32 bit sized value, offset 4 is the next etc...

Once you bother to write it up, its no big deal to use and you will get some
very useful results.

Regards,

[email protected]

------------------

[Michael Mattias]

I was at my girl friends hoouse last night so I brought my Petzold
book along ....

Remind me to never again complain about the quality of my social life...

MCM

[mark smit]

Michael,

I should explain, My girl friend has been quite sick lately so
I go over there to help her out and to keep her company. I bring
my books just in case she falls a sleep before I do. I have to
admit it did sound kinda funny in my first message.


Thank you, All for your help...


------------------
Cheers

[This message has been edited by mark smit (edited October 27, 2000).]

[Lance Edmonds]

Sure, of course we believe you...