RE: [fltk.general] Exception triggered by fl_vertex.cxx in my program [General Use]

[MacArthur, Ian (Leonardo, UK)]

> I've attached a file to this message that shows the code in the
> aforementioned .cxx file from the FLTK libraries that triggered an
> exception I've encountered. The file also shows the unhandled exception
> messages I get when I run the code in the debugger without catching the
> exception.

> The main problem right now is that I can't see anything on my window.
> No error message for the caught exception shows up on the window.

> I've also attached my code and the library interface headers and .cpp
> files provided by Dr. Stroustrup for the book I'm using, along with
> other code I'm directly or indirectly. [There are four headers for a
> Matrix, but I'm not using that so I decided to not attach those ones.]


Hmm, from the look of the stuff you posted, you are trying to work your way through the exercises in Dr. Stroustroup's PPP.

But it looks like you are trying to link his wrapper files against fltk-1.4.

That seems ill-advised.

Those wrappers are old, they were designed for use with fltk-1.1.something.

I think they do work with fltk-1.3, also, but I'm not entirely sure...

I would not assume that they work with fltk-1.4, given the way it is currently in rapid flux. They probably can/should, but it is not a safe assumption at this stage.

Note, also, that Dr.S's code and examples were written for 32-bit platforms, so I suggest (once again) that your desire to build 64-bit code is misplaced.

If what you want to do is work through Dr.S's examples then I suggest *strongly* that you create a build environment similar to that which he envisaged, that is to say a 32-bit environment linking with fltk-1.1.10 (or possibly fltk-1.3.4. at a pinch.)

As an aside, I would note that (at least in my "humble" opinion) Dr.S's use of fltk in his wrappers is somewhat, umm, "idiosyncratic", and I would not recommend it as good examples of fltk programming style.




Leonardo MW Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

[Osman Zakir]

On Wednesday, May 24, 2017 at 5:01:03 PM UTC+5, MacArthur, Ian (Leonardo, UK) wrote:

> I've attached a file to this message that shows the code in the
> aforementioned .cxx file from the FLTK libraries that triggered an
> exception I've encountered.  The file also shows the unhandled exception
> messages  I get when I run the code in the debugger without catching the
> exception.  

> The main problem right now is that I can't see anything on my window.
> No error message for the caught exception shows up on the window.

> I've also attached my code and the library interface headers and .cpp
> files provided by Dr. Stroustrup for the book I'm using, along with
> other code I'm directly or indirectly.  [There are four headers for a
> Matrix, but I'm not using that so I decided to not attach those ones.]


Hmm, from the look of the stuff you posted, you are trying to work your way through the exercises in Dr. Stroustroup's PPP.

But it looks like you are trying to link his wrapper files against fltk-1.4.

That seems ill-advised.

Those wrappers are old, they were designed for use with fltk-1.1.something.

I think they do work with fltk-1.3, also, but I'm not entirely sure...

I would not assume that they work with fltk-1.4, given the way it is currently in rapid flux. They probably can/should, but it is not a safe assumption at this stage.

Note, also, that Dr.S's code and examples were written for 32-bit platforms, so I suggest (once again) that your desire to build 64-bit code is misplaced.

If what you want to do is work through Dr.S's examples then I suggest *strongly* that you create a build environment similar to that which he envisaged, that is to say a 32-bit environment linking with fltk-1.1.10 (or possibly fltk-1.3.4. at a pinch.)

As an aside, I would note that (at least in my "humble" opinion) Dr.S's use of fltk in his wrappers is somewhat, umm,  "idiosyncratic", and I would not recommend it as good examples of fltk programming style.

I'm using FLTK version 1.3.4, though, and it's not PPP1 but PPP2.  Dr. Stroustrup said in the book that later versions of FLTK should also work (it's just the steps needed for setting FLTK up are different from those outlined in the book - which Dr. Stroustrup also mentioned they might be).  Why do you think I'm using FLTK 1.4?  I wouldn't go for that yet anyway since I know it's not a stable release.  I already noticed on fltk.org that the stable releases only go up to fltk-1.3.4-1 so far.  So that's the one I downloaded.

According to Dr. Stroustrup's own words in the book, he wants his readers to write that can be ported to any GUI library and still work fine.  That might be the reason for that "idiosyncratic" use of FLTK in the wrappers.   

[MacArthur, Ian (Leonardo, UK)]

> <rant>
> The question is: why are all these templates and advanced functions
> necessary to teach a simple GUI approach? Does any reader of the book
> (do you) know what's going on under the hood? I guess no. :-(
> </rant>


Albrecht,

The student is never really meant to look at the bulk of that stuff at all.

The PPP webpage distributes a tarball with examples (and a copy of fltk-1.1.9!) and so forth, and a "GUI" folder with Dr.S's support code in it; the student is just meant to link against that support code.

So I guess that the only bit that is from Osman is the stuff in main.cpp.


But, and this is where it gets messy... This has come up with other users in the past, so I have poked at that code on occasion.

There was a tarball distributed for the PPP edition 1, that has a set of the "GUI" code, and all the examples and such like.

The PPP edition 2 webpage has a smaller tarball that includes a different version of the "GUI" code.

In my experience, it really looks like the GUI code for PPP2 is maybe not quite complete? The PPP2 code is not as neatly formatted as the stuff for PPP1, and it doesn't compile with any compiler I have tried, (except maybe MS cl compiler?) It just looks a bit "work in progress", but it's been like that since forever.
Maybe it is meant to be a challenge for the students? Do not know.

That said, the PPP1 stuff doesn't always compiler either, as it has some syntax issues that modern compilers choke on, too.

It's all a bit of a mess.


FWIW, I managed to get Osman's code to compile and link against the "GUI" code from PPP1 (not form PPP2, I couldn't make that work.)

The exe then runs, showing a grey window with one button, clicking the button causes the app to exit. The window shows no evidence of the box or line drawing that Osman's code seems to be trying to create.

Where they have gone, I do not know (stopped looking.)

The code did not throw any exceptions.

[MacArthur, Ian (Leonardo, UK)]

FWIW, I patched the PPP2 "GUI" files as Albrecht suggested, then built/tested some of the sample code from the PPP1 tarball for Chapter 13, and they pretty much worked OK.

So whatever is going on, I have to suspect it's something peculiar to the way Osman's build is working, or something?

The other examples I tried do display lines and widgets as expected, so although it looks a bit duff, the "GUI" code from PPP2 can work as needed in this case (at least once it is patched to build on non-MS cl compilers at any rate!)

[Albrecht Schlosser]

On 24.05.2017 18:37 MacArthur, Ian (Leonardo, UK) wrote:
>> <rant>
>> The question is: why are all these templates and advanced functions
>> necessary to teach a simple GUI approach? Does any reader of the book
>> (do you) know what's going on under the hood? I guess no. :-(
>> </rant>
>
>
> Albrecht,
>
> The student is never really meant to look at the bulk of that stuff at all.

That's fine. Unfortunately I had to do that to (try to) find out what's
going on. If everything works, it's okay, but if not ...

> The PPP webpage distributes a tarball with examples (and a copy of fltk-1.1.9!) and so forth, and a "GUI" folder with Dr.S's support code in it; the student is just meant to link against that support code.
>
> So I guess that the only bit that is from Osman is the stuff in main.cpp.

Hopefully...

> But, and this is where it gets messy... This has come up with other users in the past, so I have poked at that code on occasion.
>
> There was a tarball distributed for the PPP edition 1, that has a set of the "GUI" code, and all the examples and such like.
>
> The PPP edition 2 webpage has a smaller tarball that includes a different version of the "GUI" code.

Thanks for this explanation (more of it removed). I never bothered to
download and try Dr. S's code directly, mainly because of lack of time
and because I don't have "the book".

> FWIW, I managed to get Osman's code to compile and link against the "GUI" code from PPP1 (not form PPP2, I couldn't make that work.)

I used the code he posted in two different posts in this thread and
patched it with the patch posted in a recent post by me. I added a
CMakeLists.txt to be able to build it.

> The exe then runs, showing a grey window with one button, clicking the button causes the app to exit. The window shows no evidence of the box or line drawing that Osman's code seems to be trying to create.

Same here.

> Where they have gone, I do not know (stopped looking.)

I found out that his method Box::draw_lines() was never called (setting
a breakpoint in gdb as well as in VS2015 proved it). I stared at the
code and went through code of class Shape and found that
Shape::draw_lines() _is_ called. It doesn't do much though since there
are no 'points' it could draw.

The strange thing is that Shape::draw_lines() is virtual, so Osman's
Box::draw_lines() method should be called, shouldn't it?

I found out that Box is a struct, and in a desperate attempt I converted
it to a class, but without success (I didn't really expect any changes,
but you never know). Box::draw_lines() still wasn't called. That was the
point I gave up, and that's all I can do for now.

> The code did not throw any exceptions.

Neither did it here.

[chris]

>> The exe then runs, showing a grey window with one button, clicking the
>> button causes the app to exit. The window shows no evidence of the box
>> or line drawing that Osman's code seems to be trying to create.
>

> Same here.

>
>> Where they have gone, I do not know (stopped looking.)
>

> I found out that his method Box::draw_lines() was never called (setting
> a breakpoint in gdb as well as in VS2015 proved it). I stared at the
> code and went through code of class Shape and found that
> Shape::draw_lines() _is_ called. It doesn't do much though since there
> are no 'points' it could draw.
>
> The strange thing is that Shape::draw_lines() is virtual, so Osman's
> Box::draw_lines() method should be called, shouldn't it?
>
> I found out that Box is a struct, and in a desperate attempt I converted
> it to a class, but without success (I didn't really expect any changes,
> but you never know). Box::draw_lines() still wasn't called. That was the
> point I gave up, and that's all I can do for now.
>

>> The code did not throw any exceptions.
>

> Neither did it here.

As I found the pp2 sources already on my harddrive from sometime I also
gave it a try. They compile here under Ubuntu 14.04 and with current
FLTK 1.4 (with some warnings, mainly const issues).

The reason why no drawing appears is probably, because Box is
constructed as a scoped variable, so it will be immediately deleted
after the try/catch. Declaring it *static* works:

static Box box1{ box_tl, side };

This may also be the reason for the crash under Windows.

fl_begin_line();
fl_arc( ... )
fl_end_line();
...

Lines appear, but no arcs, because the arc calls are not embedded
between fl_begin_line()/fl_end_line() statements:


Adding these leads to the attached screen.

[Albrecht Schlosser]

On 24.05.2017 19:33 chris wrote:
>
> As I found the pp2 sources already on my harddrive from sometime I also
> gave it a try. They compile here under Ubuntu 14.04 and with current
> FLTK 1.4 (with some warnings, mainly const issues).
>
> The reason why no drawing appears is probably, because Box is
> constructed as a scoped variable, so it will be immediately deleted
> after the try/catch. Declaring it *static* works:
>
> static Box box1{ box_tl, side };
>
> This may also be the reason for the crash under Windows.
>
> fl_begin_line();
> fl_arc( ... )
> fl_end_line();
> ...
>
> Lines appear, but no arcs, because the arc calls are not embedded
> between fl_begin_line()/fl_end_line() statements:
>
> Adding these leads to the attached screen.

Great findings; I can confirm that this works here as well.

You are correct with both issues. If you remove the try _block_
including the curly braces {} the scope of box1 reaches until the end of
the program (or you click Exit).

Box::draw_lines() is only called if box1 lives long enough and the
missing fl_begin/end_line() causes the crash. There is a variable 'n'
that is obviously uninitialized and has a very high negative value.

@Osman: the correct fix is, as Chris found out, to add fl_begin_line()
and fl_end_line() before and after fl_arc() respectively. The 'static'
attribute is not necessary (as it seems now) since the scope of box1 is
until the end of the program if you remove the try/catch blocks.

[Osman Zakir]

Alright, thanks.  I got it up to part where the arcs still aren't being drawn right (though they're at least there now).  Could you guys help me figure this out?  Thanks in advance.  The updated main.cpp is attached to his post; here's a link to an image showing the output: http://i197.photobucket.com/albums/aa143/Osman456/gui_output_zpsnf1fmbki.png

[Greg Ercolano]

On 05/24/17 15:11, Osman Zakir wrote:
> Alright, thanks. I got it up to part where the arcs still
> aren't being drawn right (though they're at least there now).
> Could you guys help me figure this out? Thanks in advance.
> The updated main.cpp is attached to his post; here's a link
> to an image showing the output:
> http://i197.photobucket.com/albums/aa143/Osman456/gui_output_zpsnf1fmbki.png

Image shows a box with missing corners, presumably where the arcs
are supposed to go, but dots are being shown instead of arcs.

Seems the values passed to the arcs are not correct.

Try adding a printf() that prints the values being passed to one
of your fl_arc() commands to see what the x/y/radius/angles are,
and compare that to the docs for fl_arc() to see why it's not
working as expected:
http://www.fltk.org/doc-1.3/group__fl__drawings.html#ga3c1216fb40b6274acff72cca64b86a69

[Greg Ercolano]

BTW, I can't see where you're setting or adjusting m_start_deg or m_end_deg
which define the arc angles.

They should be different for /each/ of the 4 fl_arc() calls, right?

The top-left corner should draw an arc from 9 o'clock to 12 o'clock,
and the top-right corner should draw an arc from 12 o'clock to 3 o'clock,
etc..

I don't see any changes being made to the m_start_deg/m_end_deg for those
changes.

In fact, I don't see m_start_deg/m_end_deg even being initialized anywhere..

[Osman Zakir]

I initialized m_start_deg and m_end_deg in the constructor when I passed the constexpr doubles start_deg and end_deg to it in main().  Lines 42 and 43.  

For the arcs each having to have different values, I think I'll try passing in just the values for the top left corner arc and add or subtract to/from it in draw_lines() to get the other arcs' values.  That should work.  My first arc has to go from 45 degrees to 360 degrees, right?  I'll just go from there.  The ones for the bottom arcs should be the other way around from their opposite counterparts, right?  For the bottom left corner it should be 12 o'clock to 9 o'clock, and for the bottom right corner 3 o'clock to 12 o'clock.  Right?  Or is that completely wrong? 

[Osman Zakir]

And I'm sorry if this is a stupid question, but what arc is for what corner? 

[Greg Ercolano]

On 05/25/17 04:49, Osman Zakir wrote:
> On Thursday, May 25, 2017 at 4:43:26 AM UTC+5, Greg Ercolano wrote:
>> In fact, I don't see m_start_deg/m_end_deg even being initialized anywhere..
>
> I initialized m_start_deg and m_end_deg in the constructor when I passed
> the constexpr doubles start_deg and end_deg to it in main(). Lines 42 and 43.

You must be referring to a different main.cpp than I have.

I'm looking at the single main.cpp you posted on 05/24/17 (copy attached).

I'm seeing m_start_deg and m_end_deg in only two parts of the code;

1) declared private on lines 26+27
2) used by fl_arc() commands in Box::draw_lines()

No initialization, so the values will likely be 0.0 for both,
which explains points being drawn instead of arcs.

> For the arcs each having to have different values, I think I'll try passing
> in just the values for the top left corner arc and add or subtract to/from
> it in draw_lines() to get the other arcs' values. That should work.

Yes; I can't think why the arc start/end degrees would be anything
but fixed values to draw the corners.

> My first arc has to go from 45 degrees to 360 degrees, right?

While I'm not sure which corner you're thinking of as 'first',
drawing an arc from 45 to 360 would draw 315 degrees; almost
an entire circle.

Can't think why you'd want to draw a 315 degree arc when drawing
a corner.. you'd only want small 90 degree arcs, right?

> I'll just go from there. The ones for the bottom arcs should be the
> other way around from their opposite counterparts, right?

Yes, each corner would need its own 90 degree arc for a different
part of the clock, if thinking in clock analogy with 12 o'clock being "up".

> For the bottom left corner it should be 12 o'clock to 9 o'clock,

Hmm, can you draw a diagram showing how you're thinking of this?
It's not clear to me how you'd arrive at 12-9 for any corner..

Here's my diagram of how to think of this:
http://seriss.com/people/erco/fltk/tmp/rounded-corners.png

..bottom left would be 6 o'clock to 9 o'clock; a 90 degree arc.

In FLTK's fl_arc() terms, the docs say:

"start and end angles of arc measured in degrees counter-clockwise from 3 o'clock.
a2 must be greater than or equal to a1."

..so keep that in mind when converting clock analogy thinking
into degrees; 0==3 o'clock, 90=12 o'clock, etc.

> and for the bottom right corner 3 o'clock to 12 o'clock. Right?
> Or is that completely wrong?

No, bottom right would be 3 to 6.

[Osman Zakir]

You said 9 to 12, so I drew an arc from 45 degrees to 360 degrees (start_deg=45, end_deg=360).  And yeah, it came out as an-almost-full circle.  So I just have to have it start at 45 degrees and end wherever it equals a 90-degree angle, then?  And I do that for the others as well?  Also, which arc is for which corner?  

[Osman Zakir]

On Thursday, May 25, 2017 at 9:07:27 PM UTC+5, Greg Ercolano wrote:

I'm attaching the updated main.cpp to this message. 

[Greg Ercolano]

On 05/25/17 09:24, Osman Zakir wrote:
> > and for the bottom right corner 3 o'clock to 12 o'clock. Right?
> > Or is that completely wrong?
> No, bottom right would be 3 to 6.
>
> You said 9 to 12, so I drew an arc from 45 degrees to 360 degrees (start_deg=45, end_deg=360).

Hmm, where is 45 coming from?
The only angles you want will be 90 degree increments, not 45.
Which is to say 0, 90, 180, 270.

> I'm attaching the updated main.cpp to this message.

I can't actually build your main.cpp; getting too many errors from
the other files it includes, it's too much.. stuff.. to fix
to get it working.

I've reduced the original main.cpp you'd posted to a single file
so that there's no dependence on the book's numerous files.

Here I've simplified the fl_arc() commands to just:

fl_arc(x1, y1, m_radius, 90, 180); // top left (9 -> 12)
fl_arc(x2, y2, m_radius, 0, 90); // top right (12 -> 3)
fl_arc(x3, y3, m_radius, 270, 360); // bottom right (3 -> 6)
fl_arc(x4, y4, m_radius, 180, 270); // bottom left (6 -> 9)

I can't think why those angle values need variables; they'd only
ever be fixed values.

I changed some of the code so that the window can be resizable,
and scales the rectangle to follow the window dimensions. This tests
the rounded corners calculate properly no matter the dimensions of
the rectangle. The size of the rectangle is 66% of the window size,
and I replaced the magic offsets (like +81 and +130+72) with just
the radius (as that's all those arc offsets should ever be).
_____________________________________________________________________________

#include <FL/Fl.H>
#include <FL/Fl_Window.H>
#include <FL/fl_draw.H>

typedef struct { int x, y; } Point;

class MyWindow : public Fl_Window {
public:
MyWindow(int X,int Y,const char *L) : Fl_Window(X,Y,L) { }
void draw() {
int m_height = h() * 0.66;
int m_width = w() * 0.66;
const int space = m_height / 10; // leave space for arcs
double m_radius = space; // ** radius should be same as "space for arcs"

Point m_tl{ m_width / 4, m_height / 4 };

// make the points
Point tr = m_tl;
tr.x += m_width; // top-right corner

Point br = tr;
br.y += m_height; // bottom-right corner

Point bl = br;
bl.x -= m_width; // bottom-left corner

// draw the lines
fl_line(m_tl.x + space, m_tl.y, tr.x - space, tr.y);
fl_line(tr.x, tr.y + space, br.x, br.y - space);
fl_line(br.x - space, br.y, bl.x + space, bl.y);
fl_line(bl.x, bl.y - space, m_tl.x, m_tl.y + space);

// draw the arcs

// TOP LEFT -- 9 o'clock (180deg) to 12 o'clock (90deg)
// fl_arc wants the values in ascending order, so 12-9
//
const double x1 = static_cast<double>(m_tl.x + m_radius);
const double y1 = static_cast<double>(m_tl.y + m_radius);
fl_begin_line();
fl_arc(x1, y1, m_radius, 90, 180);
fl_end_line();

// TOP RIGHT -- 12 o'clock (90deg) to 3 o'clock (0deg)
const double x2 = static_cast<double>(tr.x - m_radius);
const double y2 = static_cast<double>(tr.y + m_radius);
fl_begin_line();
fl_arc(x2, y2, m_radius, 0, 90);
fl_end_line();

// BOTTOM RIGHT -- 3 o'clock (0deg) to 6 o'clock (270deg)
const double x3 = static_cast<double>(br.x - m_radius);
const double y3 = static_cast<double>(br.y - m_radius);
fl_begin_line();
fl_arc(x3, y3, m_radius, 270, 360);
fl_end_line();

// BOTTOM LEFT -- 6 o'clock (270deg) to 9 o'clock (180deg)
const double x4 = static_cast<double>(bl.x + m_radius);
const double y4 = static_cast<double>(bl.y - m_radius);
fl_begin_line();
fl_arc(x4, y4, m_radius, 180, 270);
fl_end_line();
}
};

int main() {
MyWindow *win = new MyWindow(600,400,"Rounded-Corner Boxes");
win->end();
win->resizable(win);
win->show();
return Fl::run();
}
_____________________________________________________________________________

[Osman Zakir]

Thanks, I appreciate the help.  I'm partially done now; there's still a slight problem with the arcs that I need to fix.  Look at the output: https://1drv.ms/i/s!As6LkLqTe7Ps8GKuPiA4wXK0UXBS .  Why do the boxes come out like that?   The latest main.cpp is attached to this message.  [The book says to create and attach two objects of any class we define for exercises where we have to define a class, so that's why there are two boxes.]

[Greg Ercolano]

On 05/26/17 04:29, Osman Zakir wrote:
>
> Thanks, I appreciate the help. I'm partially done now;
> there's still a slight problem with the arcs that I need to fix.
> Look at the output: https://1drv.ms/i/s!As6LkLqTe7Ps8GKuPiA4wXK0UXBS

> Why do the boxes come out like that? The latest main.cpp is attached
> to this message. [The book says to create and attach two objects
> of any class we define for exercises where we have to define a class,
> so that's why there are two boxes.]

Make the boxes bigger in height + width.

My guess is a radius based on width/10 is ending up to be too small
to be drawn well.

I had to (again) port your code away from the book's code because
the Simple_window.h / Graph.h stuff that gets included in doesn't
build for me.

Ported it to pure FLTK / old style C++, and just made the boxes
slightly bigger, seems to look ok.

#include <FL/Fl.H>
#include <FL/Fl_Window.H>
#include <FL/Fl_Box.H>

#include <FL/fl_draw.H>

typedef struct { int x, y; } Point;

class Box : public Fl_Box {
Point m_tl;
int m_width;
int m_height;
double m_radius;
public:
Box(Point tl, int width, int height, double radius) : Fl_Box(tl.x, tl.y, width, height)
{
m_tl = tl;
m_width = width;
m_height = height;
m_radius = radius;
type(FL_BORDER_BOX);
}
void draw() {
printf("Drawing %d %d %d %d\n", x(), y(), w(), h());

Fl_Box::draw();
fl_color(FL_BLACK);

// make the points
Point tr = m_tl;
tr.x += m_width; // top-right corner

Point br = tr;
br.y += m_height; // bottom-right corner

Point bl = br;
bl.x -= m_width; // bottom-left corner

printf("m_radius=%f\n", (float)m_radius);

// draw the lines
const int space = m_radius; // leave space for arcs

fl_line(m_tl.x + space, m_tl.y, tr.x - space, tr.y);
fl_line(tr.x, tr.y + space, br.x, br.y - space);
fl_line(br.x - space, br.y, bl.x + space, bl.y);
fl_line(bl.x, bl.y - space, m_tl.x, m_tl.y + space);

// draw the arcs

const double x1 = static_cast<double>(m_tl.x + m_radius);
const double y1 = static_cast<double>(m_tl.y + m_radius);
fl_begin_line();
fl_arc(x1, y1, m_radius, 90, 180);
fl_end_line();

const double x2 = static_cast<double>(tr.x - m_radius);
const double y2 = static_cast<double>(tr.y + m_radius);
fl_begin_line();
fl_arc(x2, y2, m_radius, 0, 90);
fl_end_line();

const double x3 = static_cast<double>(br.x - m_radius);
const double y3 = static_cast<double>(br.y - m_radius);
fl_begin_line();
fl_arc(x3, y3, m_radius, 270, 360);
fl_end_line();

const double x4 = static_cast<double>(bl.x + m_radius);
const double y4 = static_cast<double>(bl.y - m_radius);
fl_begin_line();
fl_arc(x4, y4, m_radius, 180, 270);
fl_end_line();
}
};


int main() {

int win_width = 600, win_height = 600;
Fl_Window win(win_width, win_height, "Rounded-Corner Boxes");
win.begin();

Point box_tl1{ 250, 100 };
int width1 = 200, height1 = 150;
double radius1 = static_cast<double>(height1) / 10;
Box box1(box_tl1, width1, height1, radius1);
box1.color(FL_BLACK);

Point box_tl2{ 250, 300 };
int width2 = 300, height2 = 200;
double radius2 = static_cast<double>(height2) / 10;
Box box2(box_tl2, width2, height2, radius2);
box2.color(FL_BLACK);

win.end();
win.show();
win.resizable(win);

return Fl::run();
}