Announcement

Collapse
No announcement yet.

Forms as Objects

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

  • Forms as Objects

    With all the new compiler features, I am thinking to turn every thing I have into an object based system to create and manipulate Forms, controls and code.
    I think this might be a great way to make it simple and easy to maintain. It would make the project more of a departmentalized build. Different people or groups could work on separate items and not interfere with one another , we would be working of of a predefined mapped out system

    Anyone here started or finished something along theses lines.

    Any Thoughts on the matter



    -Mike
    A dozen what.

  • #2
    That's the basic underlying architectural concept of Windows, really. Windows are based on Window Classes, and one can set aside memory within each instance of a class to associate data and other objects ( child controls on the object/form ) with the parent instance. Get/SetProp() and .cbWndExtra bytes of class memory allow for that. Now one can defeat/subvert the basic design by throwing global variables and objects all over the place, but Microsoft put the basic design in place. All that needs to be done is understand it and use it.
    Fred
    "fharris"+Chr$(64)+"evenlink"+Chr$(46)+"com"

    Comment


    • #3
      Fred nice to hear from you. Did not know you where part of the VB converter or have I forgotten,

      I am trying to see if I can spark interest in this again.


      Mike
      A dozen what.

      Comment


      • #4
        Yes, I worked on it hot and heavy for the 1st couple weeks. Then I abandoned it.

        My personal opinion is that the only way to really attack it is to accept VB4 - 6 for what it was, that is, an entirely COM based technology. Every 'object' in VB was a COM component. When VB was installed, all the COM dlls housing all those components were installed and registered on the system. I haven't really worked with it, but I see no reason PowerBASIC couldn't instantiate all those components on its own and work with them exactly the way VB did.

        When I was working on it several years ago what I had done was read in and parse the *.frm/vbp files and convert their contents to SDK style Windows Api code. That was fun for a bit, but I always 'felt in my bones' it was the wrong way to go. I just wanted to see how far I could get with it.

        However, that isn't what VB did by any stretch. It never took the results from its visual designer and generated Sdk/Api code. It instantiated objects instead which was ActiveX COM code in Dlls.

        At this point VB6 represents 10 year old code, even though I'm sure there is a lot of it around yet. I really have other priorities right now, and can't take the time to work on it.

        I wish things were different. I think change is coming too fast. Too fast for me anyway.

        But I agree with the basic idea you stated when you started this thread. I think VB did a lot in terms of the idea of code modularity and encapsulation. The things I learned in the context of VB in the nineties I have adopted heavily in all my PowerBASIC work. That's why I use message cracker schemes so heavily in my SDK PowerBASIC and C++ code and handle each Windows Message in its own 'event procedure'. So while I'd have to admit that there was very little transferable from VB to PowerBASIC code, at least in terms of the Windows Api and my SDK coding style, some of the foundational architectural issues transferred quite well.
        Fred
        "fharris"+Chr$(64)+"evenlink"+Chr$(46)+"com"

        Comment


        • #5
          Unfortunately going beyond converting the GUI is seems to just short of writing a compiler.

          VB has always appeared to be to the lazy mans tool, it accepts variants and the compiler has to interrupt and adjust accordingly same thing we would have to do to covert an entire VB program.

          Enough for now , see what half backed thing I can put together for a foundation.
          A dozen what.

          Comment

          Working...
          X