Page 3 of 3 FirstFirst 123
Results 21 to 27 of 27
  1. #21
    Join Date
    Nov 2006
    Location
    UK
    Posts
    3,774
    Using a class in the muck challenge would work perfectly well. However, it then makes it more annoying to store it in the database and read it back.. Hence I think a record is all thats really needed, a record could be argued as a class without methods or events :P

    There are a lot of times when you do need a class, and if you're struggling then, post away, lets work out why! pick a class of your choosing you have floating around which is crappy and we'll fix it.
    Delphi !ROCKS!
    Got a question? Read this first!!!
    "You gotta help us, Doc. We've tried nothin' and we're all out of ideas"

  2. #22
    Join Date
    Sep 2007
    Location
    Victoria, BC Canada
    Posts
    185
    VK, excellent. A perspective I really hadn't considered ... well, I hadn't really considered any other than my own so ...

    You make some excellent points, thanks.

    In retrospect and to be quite honest, if the deadlines weren't there ... it's a toss-up. I'd like to think I'd complete them.

  3. #23
    Join Date
    Jan 2007
    Posts
    640
    I agree, when I saw you could use a record I though "doh! that would be so much simpler!" One reason why I didn't like using the class in the Muck was I'd get into circular references. Thankfully I leanred more about pointers nad was able to use records in the Profiler challenge.

  4. #24
    Join Date
    Sep 2007
    Location
    Victoria, BC Canada
    Posts
    185
    Quote Originally Posted by VelariaKnight View Post
    ... I'd get into circular references.
    Didja know you can sometimes work around these by adding the problem unit to the uses clause in the implementation section instead of the interface. I'll have to go review if you want to know more than that

  5. #25
    Join Date
    Jan 2007
    Posts
    640

    My circular reference

    Ummm... I was refering to how I declared the main object.

    Code:
    TMuckObject = class (TObject)
        private
            .
            .
            .
        protected
        public
            .
            .
             .
    
          property Loc: TMuckObject read FLoc write SetLoc;
          property LinkTo: TMuckObject read FLinkTo write SetLinkTo;
      end;
    Where as if I used a TList and a set of records it would ahve been less convoluted and simpler to load/save to disk.

  6. #26
    Join Date
    Sep 2007
    Location
    Victoria, BC Canada
    Posts
    185
    Ahhh, I see.

    I went with records, shoved them into a big array of records - it was just so convenient. You followed the rules though. I sort of did.

    Had the opportunity to have a big rant on borland.public.delphi.non-technical [see topic: OODesign approach in reality] the other day about the lack of persistence for objects in Delphi. Felt good.

    It's so stupid from a newbie perspective. The current methodology is to write code using objects ... then what? Load all the data into them and then strip it back out when you want to save it ... Bah!

    [ooops, doing it again, sorry]

    ... hooking up DA controls directly to a database, the shame of it ...
    <mumble> <mumble> <mumble>

  7. #27
    Join Date
    Nov 2006
    Location
    UK
    Posts
    3,774
    Not everything is "an object" but, your records could just simply be a propery of an object - any varaible you declare in your forms private/public areas etc are basically extending your form class.. This is why people dont realise the fact of what they're doing by making the form .. you're extending the form class

    the thread mentioned above
    Delphi !ROCKS!
    Got a question? Read this first!!!
    "You gotta help us, Doc. We've tried nothin' and we're all out of ideas"

Page 3 of 3 FirstFirst 123

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •