Announcement

Collapse
No announcement yet.

Custom controls

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Custom controls

    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

  • #2
    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


    Michael Mattias
    Tal Systems Inc. (retired)
    Racine WI USA
    [email protected]tems.com
    http://www.talsystems.com

    Comment


    • #3
      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).




      ------------------
      Chris Boss
      Computer Workshop
      Developer of "EZGUI"
      http://cwsof.com
      http://twitter.com/EZGUIProGuy

      Comment


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

        Code:
        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 -
        Code:
        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).]
        Zippety Software, Home of the Lynx Project Explorer
        http://www.zippety.net
        My e-mail

        Comment


        • #5
          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]



          ------------------
          hutch at movsd dot com
          The MASM Forum

          www.masm32.com

          Comment


          • #6
            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

            Comment


            • #7
              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
              Computer Workshop
              Developer of "EZGUI"
              http://cwsof.com
              http://twitter.com/EZGUIProGuy

              Comment


              • #8
                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.



                ------------------
                Chris Boss
                Computer Workshop
                Developer of "EZGUI"
                http://cwsof.com
                http://twitter.com/EZGUIProGuy

                Comment


                • #9
                  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



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

                  Comment


                  • #10
                    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.


                    ------------------
                    Chris Boss
                    Computer Workshop
                    Developer of "EZGUI"
                    http://cwsof.com
                    http://twitter.com/EZGUIProGuy

                    Comment


                    • #11
                      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

                      Comment


                      • #12
                        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]

                        Comment


                        • #13
                          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]

                          ------------------
                          hutch at movsd dot com
                          The MASM Forum

                          www.masm32.com

                          Comment


                          • #14
                            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

                            Michael Mattias
                            Tal Systems Inc. (retired)
                            Racine WI USA
                            [email protected]
                            http://www.talsystems.com

                            Comment


                            • #15
                              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).]

                              Comment


                              • #16
                                Sure, of course we believe you...

                                Lance
                                mailto:[email protected]

                                Comment

                                Working...
                                X