Re: [fltk.general] [FLTK 1.3] Fl_Helpview doesn't take care of br?
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. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] [FLTK 1.3] Fl_Helpview doesn't take care of br?
MacArthur, Ian (Selex ES, UK) schrieb: As a hackaround, it looks like replacingb withp/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. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] [FLTK 1.3] Fl_Helpview doesn't take care of br?
On 04/04/13 02:52, MacArthur, Ian (Selex ES, UK) wrote: 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 BRs, eg: single spaceBRsingle space BRnbsp;BR double spaceBRnbsp;BRdouble space BRnbsp;BRnbsp;BR triple spaceBRnbsp;BRnbsp;BRtriple 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. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] [FLTK 1.3] Fl_Helpview doesn't take care of br?
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/ ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] [FLTK 1.3] Fl_Helpview doesn't take care of br?
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? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] [FLTK 1.3] Fl_Helpview doesn't take care of br?
On 04/04/13 09:44, Manolo Gouy wrote:
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 BRs 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 aaabrsingle rsingle ccc
brbrdouble dddbrbrdouble eeebrbrdouble fff
brbrbrtriple gggbrbrbrtriple hhhbrbrbrtriple
iii
brbrbrbrquad jjjbrbrbrbrquad
kkkbrbrbrbrquad lll
brEND);
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.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] [FLTK 1.3] Fl_Helpview doesn't take care of br?
On 04/04/13 14:32, Greg Ercolano wrote:
On 04/04/13 09:44, Manolo Gouy wrote:
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 BRs 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.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
