Discussion:
[FLTK 1.3] Fl_Helpview doesn't take care of <br>?
Edzard Egberts
2013-04-04 09:39:19 UTC
Permalink
I tried to show some html-text for help, but Fl_Helpview doesn't take
care of <br> and mucks up formatting. Doc tells, Fl_Helpview should take
care of <br>, shouldn't it?

Is there a way to get linefeeds, as aspired in the following example. My
system shows no distance between the two lines:

#include <FL/Fl.H>
#include <FL/Fl_Double_Window.H>
#include <FL/Fl_Help_View.H>

const char* cHTML=
"<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.01 Transitional//EN\">"
"<html>"
"<head>"
"<meta http-equiv=\"content-type\" content=\"text/html;
charset=ISO-8859-1\">"
"</head>"
"<body>"
"First Line<br>"
"<br>"
"<br>"
"Second Line after 3 times &lt;br&gt;<br>"
"<br>"
"</body>"
"</html>";

int main()
{
Fl_Double_Window Win(400, 200, "Helpview");
Fl_Help_View* pHV= new Fl_Help_View(10, 10, 380, 180, "");
Win.end();
pHV->value(cHTML);
Win.show();
return Fl::run();
}
MacArthur, Ian (Selex ES, UK)
2013-04-04 09:52:36 UTC
Permalink
Post by Edzard Egberts
I tried to show some html-text for help, but Fl_Helpview doesn't take
care of <br> and mucks up formatting. Doc tells, Fl_Helpview should take
care of <br>, shouldn't it?
Hmm, yes, that does seem a bit broken...

As a hackaround, it looks like replacing <b> with <p></p> seems to do something... Any good?




Selex ES 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.
********************************************************************
Edzard Egberts
2013-04-04 11:16:25 UTC
Permalink
As a hackaround, it looks like replacing<b> with<p></p> seems to do
something... Any good?
Thank you, that solves my problem. I tried to make a little "all
inclusive" tool - one file containing program, helpfiles, info and a
picture - and that was last thing preventing me from publishing it.
Edzard Egberts
2013-04-04 16:42:57 UTC
Permalink
Post by Edzard Egberts
and that was last thing preventing me from publishing it.
http://www.edzeg.net/pt100/

Not sure, whether there is any interest, because this is a german tool
for solving a particular electronic problem, now published in an
electronics group. And I failed in writing a fltk-config-makefile, so
it's plain source. :o/
Greg Ercolano
2013-04-04 16:10:38 UTC
Permalink
Post by MacArthur, Ian (Selex ES, UK)
Post by Edzard Egberts
I tried to show some html-text for help, but Fl_Helpview doesn't take
care of <br> and mucks up formatting. Doc tells, Fl_Helpview should
take care of <br>, shouldn't it?
Hmm, yes, that does seem a bit broken...
As a hackaround, it looks like replacing <b> with <p></p> seems to do something... Any good?
Yes, <P> should give you a paragraph break.

But sometimes you want to put two, three, or four blank lines.
Another trick that seems to work is to inject &nbsp; between the <BR>s, eg:

single space<BR>single space
<BR>&nbsp;<BR>
double space<BR>&nbsp;<BR>double space
<BR>&nbsp;<BR>&nbsp;<BR>
triple space<BR>&nbsp;<BR>&nbsp;<BR>triple space

It'd be good if we could fix adjacent <BR>'s though.

I recall our html parser's source being a bit tricky to grok,
but I think I worked on a small part of it once.. will see if
I can figure this one out.
Manolo Gouy
2013-04-04 16:44:11 UTC
Permalink
Post by Greg Ercolano
It'd be good if we could fix adjacent <BR>'s though.
I recall our html parser's source being a bit tricky to grok,
but I think I worked on a small part of it once.. will see if
I can figure this one out.
I've seen that commenting out line 657 of file src/Fl_Help_View.cxx
seems to fix this problem. But does this have other negative effects?
Greg Ercolano
2013-04-04 21:32:19 UTC
Permalink
Post by Manolo Gouy
Post by Greg Ercolano
It'd be good if we could fix adjacent <BR>'s though.
I recall our html parser's source being a bit tricky to grok,
but I think I worked on a small part of it once.. will see if
I can figure this one out.
I've seen that commenting out line 657 of file src/Fl_Help_View.cxx
seems to fix this problem. But does this have other negative effects?
Comment out the 'hh = 0;' line? Interesting:

--------------------------------------------
else if (strcasecmp(buf, "BR") == 0)
{
if (line < 31)
line ++;
xx = block->line[line];
yy += hh;
hh = 0; // <-- COMMENT THIS OUT
}
--------------------------------------------

That does seem to allow multiple <BR>s to work.

But also seems to badly affect the document height calculations
such that the scrollbar doesn't let one reach the bottom of the document.

For instance:

#include <FL/Fl_Help_Dialog.H>
int main() {
Fl_Help_Dialog *help = new Fl_Help_Dialog();
help->value("single aaa<br>single bbb<br>single ccc"
"<br><br>double ddd<br><br>double eee<br><br>double fff"
"<br><br><br>triple ggg<br><br><br>triple hhh<br><br><br>triple iii"
"<br><br><br><br>quad jjj<br><br><br><br>quad kkk<br><br><br><br>quad lll"
"<br>END");
help->show();
return(Fl::run());
return (0);
}

With 657 left alone, one can view the above document up to the last line (END)
using the scrollbar.

But with 657 commented out, the document becomes larger (due to the extra lines
the working <BR>'s now do), but the bottom lines are cut off in the window,
and there's no scrollbar. One can enlarge the window vertically to see the missing
lines.

Perhaps block->h needs to be adjusted for this to work correctly.
Greg Ercolano
2013-04-04 21:57:00 UTC
Permalink
Post by Greg Ercolano
Post by Manolo Gouy
I've seen that commenting out line 657 of file src/Fl_Help_View.cxx
seems to fix this problem. But does this have other negative effects?
[..]
That does seem to allow multiple <BR>s to work.
But also seems to badly affect the document height calculations
such that the scrollbar doesn't let one reach the bottom of the document.
[..]
Perhaps block->h needs to be adjusted for this to work correctly.
OK, looks like to solve the scrollbar issue, one has to comment out
the corresponding "hh = 0;" line in the Fl_Help_View::format() function.

So I think together these two changes work a bit better (still not sure
if there are other negative effects):
_____________________________________________________________________________

--- Fl_Help_View.cxx (revision 9857)
+++ Fl_Help_View.cxx (working copy)
@@ -654,7 +654,7 @@
line ++;
xx = block->line[line];
yy += hh;
- hh = 0;
+ //hh = 0;
}
else if (strcasecmp(buf, "HR") == 0)
{
@@ -1298,7 +1298,7 @@
xx = block->x;
block->h += hh;
yy += hh;
- hh = 0;
+ //hh = 0;
}
else if (strcasecmp(buf, "CENTER") == 0 ||
strcasecmp(buf, "P") == 0 ||
_____________________________________________________________________________

It looks like Help_View::format() and Help_View::draw() methods
depend on each other's code to be symmetrical.

I usually find code like this hard to maintain if managed in separate
functions, because it's too easy for the code to get out of sync.

I usually try to keep symmetrical code designs such that each block
of code is kept close together, so other programmers can clearly
see modifying one code block affects the other, eg:


void HtmlClass::Handle_BR(..) {
if (formatting) {
..code to handle <BR> formatting..
} else {
..code to handle <BR> drawing..
}
}

I've had to do this sort of thing with complex state machines
and receive/transmit code.. works well when the code blocks are short,
so it's easy to see matching code in a single page.

Loading...