1. widgets
Hi guys,
I have just learned from Lee West that chdir() function is quite new,
and people with older version of Euphoria cannot use my widgets. If
you are one of those left behind and want to try them, please replace
line 3632
o = chdir(o[n][D_NAME])
with
system("cd " & o[n][D_NAME], 2)
And similarly, line 3654
o = chdir(cudi) -- restore home dir
with
system("cd " & cudi, 2)
Or better still, upgrade!
jiri
2. Re: widgets
Hey Jiri,
Although I haven't had a chance to play with your widgets (that kinda sounds
funny, doesn't it) I sure like the professional looking results of your
travelling salesman demo. I think that documentation is in order. I know
I'd be more apt to use the lib with good doc's available and I'm sure many
other's would too.
-- Brian
3. Re: widgets
Jiri,
Most of what I do with programming these days would not be happening at all
with the direct contributions that you so kindly shared with all us in the
past. So don't think that DOS is Dead. Not by a long shot. In fact, as
M$ becomes more and more less-necessary to the programmers and end-users
out there, what they say is 'progress' also becomes moot.
Just want to once again say THANKS and you keep going.
Regards,
Norm
4. widgets
- Posted by jiri babor <jbabor at PARADISE.NET.NZ>
Aug 10, 2000
-
Last edited Aug 11, 2000
Hello again, my fellow dos dinosaurs,
Sorry, I did not keep my word. Only yesterday I realized, I was
fighting a losing battle. I gave up and packed every thing that's
working and sent it to Rob. I hope included examples will help you
make some sense of it all. And I *will* return to the docs as soon as
I find my way out of the cluster of crises surrounding me at present,
but it may take a couple of weeks, or even a month.
Sorry again. jiri
5. Re: widgets
Hi, tacitus,
You wrote:
>the msgbox.e name conflicts with same-named routine in euphoria
>include folder
Sorry, that's really stupid. I have just changed it to mbox.e.
>in higher resolutions, my rat leaves an ugly trail behind it.
>use_vesa() doesn't fix.
use_vesa() would not fix it, because it is used internally in
widgets.e anyway. This is the first time I have heard about it, it has
always worked for me on all machines in all resolutions, but there are
so many weird graphics cards out there these days...
>i'd like a library function that returns:
>-the user's default resolution in windows; and/or
>-the highest resolution of which the card and monitor are capable;
The first bit is no doubt possible, but of very little value to the
dos programmer, and the second one I guess truly impossible because I
can't really even imagine how to interrogate the monitor.
>the widgets look really cool in high resolution, except for the
>poorly house-trained rat, and the fact that the default font is quite
>small.
And I thought it was too big ;), but I rarely use higher resolutions
than 800x600. The default font is Colin Taylor's sysb13.f, but you can
choose any other font you like. There are literally hundreds of them
floating around. All you have to do is to load it somewhere at the top
of your program and assign its handle to the global variable
default_font. In fact almost every bit of text is a widget (an object
in OOP terms) that carries a complete set of properties with it. And
they all can be changed at any stage. There are numerous examples of
how to do it included in the package.
>in the various controls displaying text, such as sle or reader, text
>including a tilde "~" adopts the hotkey behaviour of a tilde - i.e.
>the tilde disappears and the letter(s) following the first tilde
>change to the hotkey colour until you get to the next tilde. this is a
>problem because dos filenames so often include tildes. in an sle
>control, the behaviour is doubly baffling to the user, because it
>only happens after you press enter. the sle then returns the full
>text to the program but only displays the tildeless text.
Interpretation of the tilde depends on the 'hilite' text attribute.
The default for widgets is 'hilite on'. It means that every tilde
encountered in the text acts as a toggle between normal and hilite
foreground color (hotkey color). But the hilite attribute can be
easily switched off; the tilde is then shown as usual. The file
selector is probably the best example to follow.
>i really think the documentation is hard for learners.
It's even worse than that, it is non-existent. I included a lot of
examples - a lazy way of dealing with the problem, if you wish, but I
really do not know how to construct good, or even adequate docs for
such complex topic. I know of only about ten people really interested
in using the widgets, and they range, as far as I can judge, from
complete novices to very experienced programmers. So where do I start
if I really do not want to spend the rest of my days writing
documentation, an activity that I hate just as much as any other
programmer?
>to fetch the selected choice of two radio buttons, i eventually came
>up with this, which looks far too long to be correct:
>
>object recursion, non_recursion, selection
>recursion = part(recurse_buttons, 257 & "Recursive")
>non_recursion = part(recurse_buttons, 257 "Non-recursive")
>selection = item(recurse_buttons, "sel")
>if selection = non_recursion then
>return 0
>elsif selection = recursion then
>return 1
>else return -- error message handler
>end if
Your approach is essentially correct, but you can achieve exactly the
same thing with a one-liner:
return part(recurse_buttons, 257 & "Recursive") = item(recurse_buttons, "sel")
With just two coupled radio buttons, one of them must always be
selected. Your 'else' clause is redundant. Btw, would not a simple
checkbox (say "Recurse") be a better choice?
>is there an easier way, or should i be writing a library like
>win32lib? if latter, wouldn't external library written like this be
>slow? (did you notice that hint, jiri?)
Sorry, tacitus, I am a bit on the slow side, I have no clue what you
are talking about. Your hint is way too subtle...
>an area i struggled with was knowing what items and components were,
>both in terms of what they represent and what they return.
It's really incredibly simple. Let's see whether I can summarize it in
less than a dozen lines:
An instance of a widget is a sequence, a list of labeled items. When
the widget is created, this list is appended to the main global
sequence wid, and from then on the widget is identifiable by its index
into the main sequence. Individual items of the list describe various
aspects of the widget, its properties, if you like. So for example
"box" is a label for a sequence {x,y,width,height}, "sho" (short for
'show') contains routine_id of the procedure to display the widget,
etc. Often there is just one special item in this list of properties
which is labeled "par" (short for 'parts'). It is nothing more than a
labeled sublist of component widgets, their own wid indices.
Well, that's ten lines exactly and I did not even try terribly hard:).
>for example, when working with radio buttons, i print()ed the indexes
>of each button and got 75,77,79 and 81 - completely random numbers to
>me, which is one of the reasons i ended up with the above code. there
>are some items that are not documented at all, such as "sta" (?????).
I hope the 'completely random numbers' make more sense now. Those
awful abbreviations are another story: at one stage I became quite
obsessed with speed. Since lists with longer labels take longer to
search, I went through the lot and vandalized almost all labels to
only three letters. Stupid. The speed advantage is so minuscule, it's
almost undetectable, and the whole thing has become unrecognizable
nightmare, unless of course your English is as bad as mine.
>i'd be happy to help with documentation if i was confident i knew
>what i was writing about. (i actually know something about writing).
You are on. When can you start?
>in the demos, there was a line p(w) or something like that. i
>couldn't find any documentation on it at all. can anyone tell me what
>it does?
pw(widget_index). It is a crude debugging tool declared at the very
end of widgets.e. It uses Pete's smart_print to show widget's
properties in a sort of 'pretty print' format.
Thanks, tacitus!
jiri
6. Re: widgets
jiri
thanks for detailed response. i'll just deal with a few things generally
here and i'll get in touch by private email about the documentation project.
i think the lack of interest in the widgets is partly due to the fact that
they are hard to use. i'll suggest a staged plan of attack for the
documentation so they become more user-friendly soon, without involving too
much commitment.
most of my other queries were actually directed at this issue - the widgets
becoming more friendly.
i don't understand why the user's default display settings would be
irrelevant to a dos programmer. what i had in mind is that the defaults
could be set so that a widget program looked and operated just like
windows, so the user would feel immediately comfortable.
i wasn't really thinking of interrogating the hardware. i thought that
windows had these hardware settings stored somewhere, and it would be just
a matter of ransacking the windows system files to locate it. i think
user.dat has some of them. if i change my monitor, windows sometimes tells
me, so presumably it has the current monitor properties recorded (but on
second thoughts, this probably only directs it to the correct drivers, not
the resolution options).
your point about the font demonstrates that different people like different
fonts and sizes - it would be nice to be able to find their preference on
their system - but good defaults are also important. because i liked a lot
of the defaults, it meant i could worry about other things on my program.
my point about the tilde was along the same lines - that for the reader or
edit box, the default should be hilite off (although i hadn't figured out
how to do it).
i thought your one-liner for the radio buttons was really neat (i wouldn't
have thought of it in a million years) but if i'm not mistaken the concept
would only work for 2 buttons. my first effort involved 4 buttons, and then
my code looked quite amateurish. by wrapping these things in chocolate,
more people will want to taste them.
i'll be in touch - may also comment on your little major bidding system.
cheers, tacitus
7. widgets
I am calling my fellow dos dinosaurs again, a sadly dwindling herd:
few weeks, ago when I finished about 22nd rewrite of my widgets, I
liked it so much I actually used it. The program is a crude Travelling
Salesman Problem's solution, and Rob has just included it in the
Recent User Contributions. It demonstrates just a small subset of the
widgets, but enough, I hope, to give you the essential flavor of the
thing.
Why? Because I am not really sure what to do with it. As I said, I am
quite happy with it as it is, but I realize decent documentation will
be required by anybody else foolish or desperate enough to play with
it. I am not talking about 17 Mbytes help file in compressed form, of
course, but it would still require a substantial effort on my part to
bring the docs up to date. And I am not willing to spend any more time
on it unless I get some indication that at least a handful of people
are interested...
Either way, I'll send the complete set with just rudimentary help file
to Rob in a day or two, so you will have a better idea what's
involved. And for those, who never bothered, just a brief description:
widgets.e : the core of the system. A 'Swiss army knife' style
utility, incorporating the latest versions of my font include,
associative lists, versatile mouse routines, an events manager
with the necessary global definitions, a common text widget as well
as a number of other frequently used routines and one or two
debugging tools.
about twenty widgets, raging from simple buttons and checkboxes to
more complex draggable windows, scrollable list boxes, even a
complete file selector. Each defined in its own include file and
with its own short test/demo program.
some very rough docs plus a handful of font files used in the demos.
So, please, let me know, if you are really interested, privately if
you wish, I shall be discrete ;).
jiri
8. Re: widgets
Jiri Babor writes:
<snip>
> widgets.e : the core of the system. A 'Swiss army knife' style . . .
</snip>
Jiri's Swiss army knife software . . . fascinating.
-- Mike Nelson
9. Re: widgets
Jiri,
Great package! I vote for extensive documentation. 
Thanks!
ck
> bring the docs up to date. And I am not willing to spend any more time
> on it unless I get some indication that at least a handful of people
> are interested...
10. Re: widgets
>Jiri's Swiss army knife software . . . fascinating.
>
>-- Mike Nelson
Believe me, Mike, you were on my mind when I inserted the phrase :)
jiri
