Hi Cosmin -- Thanks, as always, for your response. Everything you said makes good sense. And I think I probably will just go with plain text for now and worry about RTF later. For what it's worth, let me respond to each of your points.
First, about the setItems property--yes, you are absolutely correct. I can get rid of it, and will. I often just use boilerplate text when setting up object lists; that's what I did here. I made the work procedures have aText parameter, rather than outlineEntry parameters, because I figured it would make life easier once I added in a user interface. Whether I was using a TMemo, TRichEdit, or even something else, I was thinking the easiest way to identify what entry the user had selected would be via the text that was displayed on the screen at the time. Perhaps I should think differently? ... If the user has the caret on a particular line in an outline, and wants to indent it, how will the TOutline object "know" which outlineEntry to change? Finally, you are right, I am not implementing a strict tree structure. I still have the message you sent me before suggesting that I use a tree. After getting your message I spent a fair amount of time trying to understand how they worked. I even started to create a simple tree for my own use. As I learned more, though, I decided my needs were much simpler than those for which trees are designed--I didn't need anything that complex. A lot of what I saw regarding trees, for example, related to how great they were for searching and sorting large numbers of entries. I, on the other hand, am talking about something with minimal searching, no real sorting, and probably only a dozen or two entries. ... After trying to implement a simple tree, I ended up thinking all I really needed was a simple linked list, and then (after exploring that for a little while) decided I didn't even need that much! [Now you see what I've been doing in between my last post and this one ... along with working once in awhile :-)] Thanks again for your response. I appreciate the clarity and simple language. -- Al p.s. For the way the outline is "supposed" to work when you move items up or down, if you check out MS Word's outline function, it doesn't actually work the way you would expect. To get the kind of behavior you illustrated, you would need to have first "collapsed" Ind3. If you don't do that, you'll end up with | <sample> | Ind1 | Ind2 | Ind3 | Ind2.1 | Ind3.1 | </sample> ----- Original Message ----- From: "Cosmin Prund" <[EMAIL PROTECTED]> To: "Borland's Delphi Discussion List" <[email protected]> Sent: Tuesday, October 28, 2008 11:22 AM Subject: RE: Separating UI and Domain | On Tuesday, October 28, 2008 1:11 AM Alan Colburn wrote: | Subiect: RE: Separating UI and Domain | | | > However, here are the method signatures for the two classes I've been | > talking about (note that TOutlineEntry will eventually have another | > field added, pointing to a collection of a totally different data | type- | > -but we won't worry about that yet: | > | > <code> | > [look for the code in the original post] | > </code> | | Why do you have a "set" procedure for the "items" property? Depending on | how you've implemented that it would get into trouble or confuse you | later. I just don't see what you might use the "set" procedure for! | | Why do all the work procedures (moveOut, moveIn, moveDown, moveUp) take | an "aText:string" parameter? Shouldn't those procedures take a parameter | of type TOutlineEntry? | | Finally, you're not really implementing a tree structure. That's a basic | list with an extra indent level property. It works this way too, but it | is far from optimal. Here's an example: | | <sample> | Ind1 | Ind2 | Ind2.1 | Ind3 | Ind3.1 | </sample> | | What happens if you move the "Ind3" up? This is what should happen: | | <sample> | Ind1 | Ind3 | Ind3.1 | Ind2 | Ind2.1 | </sample> | | > I don't know what I want my UI to look like yet, but I am thinking | > about mimicking the interface you'd use in Word's outline view. I | > could, however, have my own "outline view" (form) where users are | > working in plain text, and any special formatting of outline text is | > done in another part of the program (e.g., formatting could be dealt | > with in a different form ... it could be that when a certain level of | > sub-heading is written in a paper, it should always be indented and | > italicized, or a title should always be centered. It seems like I'd be | > shaping the UI to the code, but it might work fine for my purposes.) | | You're mixing rich text editing with other problems. Does this project | absolutely require rich text formatting? If it doesn't then just skip it | all together! If it does skip rich text editing for now and fix it after | it works fine with plain text. Working with text editors is easy if you | use them for what they're made (editing unstructured plain/rich text). | But you want to use them for editing something that's highly structured! | | If on the other hand this is not an learning project then make a nice | "use case" diagram and figure out how the end-user will be using your | application. The GUI will most likely dictate the "Domain" stuff, | because the GUI is the most important thing in a productivity | application. (OpenOffice is not really eating out Microsoft Office's | market share, even those any document may be written using ither one of | those). After you know exactly how the GUI needs to work you'll need to | create appropriate data structures to support the model. | | -- | Cosmin Prund | _______________________________________________ | Delphi mailing list -> [email protected] | http://lists.elists.org/cgi-bin/mailman/listinfo/delphi | _______________________________________________ Delphi mailing list -> [email protected] http://lists.elists.org/cgi-bin/mailman/listinfo/delphi
