On 03.03.2013 17:15, edgar wrote:
>>> User selects a quit button which destroys all dynamically allocated =
>> widgets.
>>
>> This step is probably unnecessary - if you program is ending, and the =
>> process in which it runs is ending, then all the allocated memory will =
>> be released by the process anyway... In which case actually making the =
>> effort to explicitly destroy allocated widgets is nugatory work...
>>
> Eventually, I'd like this to be a portion of a larger program. (eg. this
> would be one choice from a drop down menu... )In that case, is it more
> important to destroy widgets that go out of scope?
It depends, there is no clear rule. However, usually you'd have a fixed
and relative small amount of widgets (say: 5 - 25) in one window or
group that you would hide and show as needed. Even if there were 100 or
more widgets, it wouldn't matter much, given today's computer memories.
OTOH, creating and destroying widgets could result in memory
fragmen-tation, which you wouldn't want. So, yes, most user interfaces could
IMO be hidden and shown as needed, in contrast to being created and
destroyed.
As a different example, I have a FLTK app that creates and destroys its
widgets regularly, since these widgets are created as a response to
a server sending something like commands to build the UI - the client
(app) doesn't know which widgets could be reused later, so this is
the only feasible way.
...
>> - There are better ways to draw lines in fltk; where did you get this =
>> approach from? It looks really quite... odd...
>
> I took a code snippet from Greg Ercolano's tutorial website. This was the
> only drawing tutorial I could find - it was written to draw an X that could
> be resized and it works great for that. I tried to modify the code to meet
> my needs, but I realized I must be making things more awkward then necessary.
Yep, let's take a look at your code and why it is "wrong". I'll
pick only the draw() method, and I'm looking forward to Ian's
example code (I don't want to duplicate his work).
Warning: what I show here shouldn't be used as such - it is not
feasible to use one widget per line, as will be shown by Ian (yes,
I'm sure about that ;-) ).
You wrote:
> void draw() {
> // DRAW BLACK LINE
> fl_color(FL_BLACK);
> fl_line_style(FL_SOLID, 2);
> int x1 = x(), y1 = y(), x2 = w(), y2 = h();
> fl_line(x1, y1, x2, y2);
> }// modified from G. Ercolano's cheatsheet (Draw an X)
> }; // When this is resized it gets funky so I think I don't have it
> // quite right...
Now, why is it getting funky when resized? You're mixing width
and height values [ w(), h() ] with absolute coordinate values
[ x2, y2 ] in the line drawing code. FLTK's resize mechanisms,
however, rely on the widget position(s) and size(s) as given by
x(), y(), w(), and h(). That said, a better draw() method would
be:
void draw() {
fl_color(FL_BLACK);
fl_line_style(FL_SOLID, 2);
int x1 = x(), y1 = y(), x2 = x() + w(), y2 = y() + h();
fl_line(x1, y1, x2, y2);
}
However, this would draw a diagonal line through your widget, from
the top-left to the botton-right corner. So, if you want to draw
horizontal and vertical lines, you could reduce the width *or*
height to 1, respectively, which would result in an almost horizontal
or vertical line. For some reasons it wouldn't be possible (wouldn't
work as expected) to use 0 width or height, but you could check if
w() or h() is 1 and draw a horizontal line instead, if you like
[though see below, why 1 doesn't work either].
After you changed the draw() method, you'd have to adjust the
coordinates of your DrawLINE widgets, set the window to being
resizable, and ... resizing ought to work as expected.
Here's what I tried, and this works (almost) as expected:
void draw() {
// DRAW BLACK LINE
fl_color(FL_BLACK);
fl_line_style(FL_SOLID, 2);
int x1 = x(), y1 = y();
int x2 = x1 + ( w() < 4 ? 0 : w() );
int y2 = y1 + ( h() < 4 ? 0 : h() );
fl_line(x1, y1, x2, y2);
}
Now the staff lines look:
// Draw Staff
line1 = new DrawLINE(100, 100, 200, 1);
line2 = new DrawLINE(100, 110, 200, 1);
line3 = new DrawLINE(100, 120, 200, 1);
line4 = new DrawLINE(100, 130, 200, 1);
line5 = new DrawLINE(100, 140, 200, 1);
vert1 = new DrawLINE(300, 99, 1, 41);
vert2 = new DrawLINE(298, 99, 1, 41);
vert3 = new DrawLINE(292, 99, 1, 41);
The end of the SimpleWindow c'tor is then:
...
end();
resizable(this); // window can now be resizable
show();
}
If you try this code, you'll see that resizing works as
expected until the DrawLINE widgets are stretched so far that
w() and/or h() >= 4 (see code above).
Knowing how resizing works, this was to be expected as well,
and that's why I used "w() < 4" and not "w() == 1" in my
experimental draw() method.
As I said above, this was only to explain what was wrong with
the DrawLINE class, but this is not a solution for the real
problem. I hope, however it helps to understand what was wrong
and how it could be done better.
My real solution would be to use one widget for the staff, probably
derived from Fl_Box (but Fl_Widget is okay, too), and to draw all
lines within its draw() method - and I assume that's what Ian will
show in his proposal as well, but there are certainly many ways to
do it.
And for the selection of notes, it would also be possible to use
a piano keyboard, like this one here:
http://prodatum.sourceforge.net/screenshots/v0.99/keyboard.png
I don't know how it was done finally, but when we discussed it here
in fltk.general many months ago, I proposed using one widget for the
entire keyboard and to draw() it with fl_rect() and fl_line(), and
that is also what I would propose today. Hint: try implementing such
a draw() method w/o looking at the code at sourceforge. Picking the
correct key/note with the mouse would then be done in the handle()
method...
HTH
Albrecht
_______________________________________________
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
