i am not able to figure ot the starting point of this

This is a discussion on i am not able to figure ot the starting point of this within the C++ Programming forums, part of the General Programming Boards category; to write two classes, screen and field, representing a screen layout and an individual field (either a label or an ...

  1. #1
    Registered User
    Join Date
    Oct 2004
    Posts
    4

    i am not able to figure ot the starting point of this

    to write two classes, screen and field, representing a screen
    layout and an individual field (either a label or an input region) that
    appears on a screen.

    The field class, which lets us display, and possibly edit, a character
    string, is really intended as a base class from which we'll derive many
    kinds of field (displaying/editing different kinds of data) in the
    future. Because of this, and because the code for the screen class will
    use the field class extensively, it is important that the screen class'
    logic uses only features of the field class described below and not
    extra features you may decide to add to the field class.

    When instantiated a field must be passed between three and five values,
    in the following order:
    - required: the row on which the field is to be displayed (int)
    - required: the starting column for the field (int)
    - required: the field's width (int)
    - optional: an initial value for the field (constant character string)
    - optional: editability flag (true: editable, false: display-only)

    If only three parameters are specified, the field begins empty. If fewer
    than five parameters are specified, the field is editable. Note that
    instantiating a field does not cause it to appear - there are member
    functions (below) to do that. If the coordinates specified are not
    valid, the closest on-screen coordinates to those specified are used. If
    the field width is too long to fit on the screen, the width should be
    reduced so that the field fits on the screen. Similarly, if the initial
    value is longer than the field width, only as many characters of the
    initial value as will fit are used.

    A field has the following public member functions, all of which are
    virtual:

    void display() - causes the field to be displayed on the screen. On
    systems where terminal output is buffered, this function does
    not flush the screen buffer. Note that if the field's current
    value is shorter than the field width, trailing spaces are
    displayed to fill out the field. (Such trailing spaces are not
    considered part of the data of the field, however).

    int edit() - causes the field to be displayed (as in display()) and
    then lets the user edit the field, using the keys just as
    dt_edit() does. The key code used to terminate editing is
    returned. The first time a field's edit() function is called,
    the cursor is positioned at the beginning of the field.
    Subsequent calls to edit() start the cursor where it left off at
    the end of the previous edit() call, unless the string is now
    too small (in which case the cursor is positioned just past the
    end of the string).

    In the case where the field is not editable, this function
    simply displays the field and returns 0 without waiting for any
    keystrokes.

    bool editable() const - returns true if the field is editable, false
    if it is display-only.

    void *data() - returns the address of the string currently stored by
    the field. Note that we expect that in derived classes this may
    be the address of some other kind of data being edited.

    field *clone() const - dynamically allocates another instance of the
    field, making that field a copy of itself, and returns the
    address of the copy. If a copy cannot be made, this function
    returns NULL. It is the caller's responsibility to deallocate
    the copy.

    Since dynamic memory allocation is required to implement this properly,
    the field class also has an appropriate copy constructor, = operator and
    virtual destructor.

    A screen manages up to 50 fields (although if you can remove this limit,
    you are more than welcomed to do so). The fields are kept in order by
    when they were added to the screen - the field that was added first is
    known as field number 0, the field that was added next is known as field
    number 1 and so on. The screen class has the following public member
    functions:

    int add(int, int, int) and
    int add(int, int, int, const char *) and
    int add(int, int, int, const char *, bool) - adds a field to the
    screen, where the field added is constructed with the data
    supplied to add(). These functions return the number of fields
    in the screen after adding the field, or 0 if the field could
    not be added for some reason.

    int add(const field &f) - adds a copy of "f" to the screen,
    returning the number of fields in the screen after adding the
    field (or 0 if the add() failed for some reason).

    void display() and
    void display(bool clear) - displays all the fields managed by the
    screen, in the same order that they were added to the screen. If
    "clear" is specified and true, the screen is cleared before the
    fields are displayed, otherwise the fields are displayed without
    touching any other part of the screen. On systems that buffer
    terminal output, this function does not flush the output buffer.

    int edit() and
    int edit(bool clear) and
    int edit(int *pfield) and
    int edit(int *pfield, bool clear) - Displays all the fields of the
    screen (after clearing the screen if "clear" is specified and
    true) and then allows the user to edit them, starting at field
    number "*pfield". The user moves between fields with any of the
    following keys:

    Down arrow - moves to the next editable field
    Up arrow - moves to the previous editable field
    Tab - works just like Down Arrow
    Enter - moves to the next editable field, except when pressed
    in the last editable field of the screen, in which case it
    causes edit() to end.

    Here "next" and "previous" refer to the order in which the
    fields were added to the screen. There is a wrap-around effect,
    also, so the the next field after the last field is the first
    field, and the previous field before the first field is the last
    field.

    All other keys which terminate a field's edit() function
    terminate this function as well, setting "*pfield" to the number
    of the field from which the user exited. The key code used to
    exit the field's edit() is returned.

    If "pfield" is NULL or not provided, then editing starts at the
    first editable field the first time edit() is called, and
    resumes at the field last exited upon subsequent calls.

    If "pfield" points to an int, but that int is not the number of
    en editable field, then editing begins at the next editable
    field (where "next" is as defined above).

    If there are no editable fields on the screen, this function
    returns 0 after displaying all the fields.

    field *getfield(int i) - returns the address of field numbered "i"
    or NULL if "i" is not the number of a field.

    int remove(int i) - removes field number "i" from the list of fields
    being managed by the screen, and returns the number of fields
    left on the screen after removal. If "i" is not the number of a
    field, then nothing happens and the current field count is
    returned.

    Note that removing a field renumbers the remaining fields.

    Also, the += operator can be used, with a screen on the left and a field
    on the right, to add a field to a screen, returning a reference to the
    screen.

    Note that creating a screen, adding a field to a screen, or removing a
    field from a screen causes no immediate visual effect. It is when the
    screen is display()ed or edit()ed that the user sees anything.

    Note also that since adding a field involves copying the field, and
    since we plan to derive new types of field in the future, you must make
    the copies of fields by using clone(), rather than by relying on the
    copy constructor.

    Since this means that your screen must use dynamic memory allocation
    (clone() dynamically allocates a copy), you should be sure to code an
    appropriate copy constructor, = operator and virtual destructor for the
    screen class.

    Both the screen class and the field class should be declared in a header
    file screen.h, and coded in a source file screen.cpp. Including screen.h
    should also make the dtio functions available for use.

  2. #2
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,761
    It looks like you've just puked your homework onto the board.

    Assuming that you did any of your previous homeworks, you should be able to make some kind of attempt at solving the problem. If you do at least that much, then we'll help you with the bits you're really stuck on.

    Until you demonstrate some kind of effort on your part, few people will be inclined to simply hand over an answer.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  3. #3
    Registered User
    Join Date
    Jun 2004
    Posts
    722
    First write the classes declaration and their methods and fields.

  4. #4
    Registered User
    Join Date
    Oct 2004
    Posts
    120
    Holy cow batman, thats a long homework assignment. I might of read through it all if you were my sister, but your not...Post some of your own code that your stuck on, I'll read that.

  5. #5
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,598
    What do you people do while in class? Obviously you are not listening or there are some very very bad programming profs/teachers out there.

  6. #6
    Registered User stillwell's Avatar
    Join Date
    Aug 2004
    Posts
    80
    I have a horrible teacher. I learn much more on my own hand, reading and looking a at tutorials and topics here.

  7. #7
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,761
    > Obviously you are not listening or there are some very very bad programming profs/teachers out there.
    Heh - probably makes no difference whether it's a ^ or a |
    Given the number of void main profs out there, I would never bet against the latter.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  8. #8
    Registered User
    Join Date
    Sep 2004
    Posts
    719
    my c++ teacher is horrible.......i have no doubt she knows more than i do, but i think i could teach the class WAY better than she can...she is unorganized and never understands a question...she gets way off track and instead of teaching the course material she ends up explaining level 1 techniques to those who never understood them rather than helping those select few outside of class....5 weeks in and i honestly don't think i've learned anything new...

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Struct Program to find Point in Rectangle
    By DMJKobam in forum C++ Programming
    Replies: 2
    Last Post: 04-09-2009, 09:56 PM
  2. For the numerical recipes in C types!
    By Smattacus in forum C Programming
    Replies: 5
    Last Post: 10-28-2008, 08:57 PM
  3. point to point
    By robarm4 in forum Game Programming
    Replies: 3
    Last Post: 05-02-2007, 12:08 PM
  4. Point passed rectangle...
    By Hunter2 in forum Game Programming
    Replies: 15
    Last Post: 10-10-2003, 10:57 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21