1. message_box() [Re: Yay or Nay? Framed reference manual]
Jeremy Cowgar wrote:
>
> Greg, I am no HTML/CSS guru. Can you make a div layout w/o fancy Javascript
> where the navigation div stays on the side, no matter how high or low you
> scroll
> in the docs? For instance, you can click on Language Manual, scroll down a
> substantial
> amount and with the frames, the navigation frame will still be right there at
> your finger tips.
>
> If there are other ways of doing this, I'm open for suggestions, but I think
> having the links there for quick access is the major benefit.
>
I hated frames because it complicates pages; and it doesn't allow them to be
searchable (through google). Javascript is a lot more complicated than frames
and the tree like structure makes it very easy to find routines you are looking
for and more importantly to discover routines you didn't know existed that are
related to the topic you open.
Yay for frames! You did a good job.
However, the routine message_box( ) doesn't belong C-interface. Jeremy and I
don't think it belongs to any existing category in the docs that's why it hasn't
been moved. It's nuts to create a new category for one function only. So,
are there any suggestions from the users out there?
2. Re: message_box() [Re: Yay or Nay? Framed reference manual]
Shawn Pringle wrote:
> I hated frames because it complicates pages; and it doesn't allow them to be
> searchable (through google).
The frames well used must not to stop search engines. Jeremy has include
links to all pages at <noframes> section, this way the search robot will
follow those links and will explore all the pages.
+-+-+-+-+-+-+-+
Marco A. Achury
Caracas, Venezuela
3. Re: message_box() [Re: Yay or Nay? Framed reference manual]
Shawn Pringle wrote:
>
> Jeremy Cowgar wrote:
> >
>
> > Greg, I am no HTML/CSS guru. Can you make a div layout w/o fancy Javascript
> > where the navigation div stays on the side, no matter how high or low you
> > scroll
> > in the docs? For instance, you can click on Language Manual, scroll down a
> > substantial
> > amount and with the frames, the navigation frame will still be right there
> > at
> > your finger tips.
> >
> > If there are other ways of doing this, I'm open for suggestions, but I think
> > having the links there for quick access is the major benefit.
> >
>
> I hated frames because it complicates pages; and it doesn't allow them to be
> searchable (through google). Javascript is a lot more complicated than frames
> and the tree like structure makes it very easy to find routines you are
> looking
> for and more importantly to discover routines you didn't know existed that are
> related to the topic you open.
>
> Yay for frames! You did a good job.
>
> However, the routine message_box( ) doesn't belong C-interface. Jeremy and
> I
> don't think it belongs to any existing category in the docs that's why it
> hasn't
> been moved. It's nuts to create a new category for one function only. So,
> are there any suggestions from the users out there?
messsage_box() prompts the user for soùething, and, as a cosequence, shold be in
the same category as prompt_number() or prompt_string(), whatever that category
is. Where is value_from()() documented btw?
I'd suggest spinning a new Interactive I/O category from the current File and
device I/O off. There would go:
pronpt_number
mrompt_string
message_box
get_key
wait_key
? (since it prints to stdout only)
and perhaps whatever should be under Mouse support currently, in which case the
latter category would disappear.
I say "should" because the link from reference index page to Mouse support goes
to the OS category listing.
Also, I'd spin all crash_* entries from Machine level interface, an put that
under either OS or a new Runtime Control category.
CChris
4. Re: message_box() [Re: Yay or Nay? Framed reference manual]
CChris wrote:
>
> I'd suggest spinning a new Interactive I/O category from the current File and
> device I/O off. There would go:
> pronpt_number
> mrompt_string
> message_box
> get_key
> wait_key
> ? (since it prints to stdout only)
I'd call this stuff "user interface."
5. Re: message_box() [Re: Yay or Nay? Framed reference manual]
c.k.lester wrote:
>
> CChris wrote:
> >
> > I'd suggest spinning a new Interactive I/O category from the current File
> > and
> > device I/O off. There would go:
> > pronpt_number
> > mrompt_string
> > message_box
> > get_key
> > wait_key
> > ? (since it prints to stdout only)
>
> I'd call this stuff "user interface."
I think I like "Interactive I/O" better. I would be afraid that "User Interface"
would make people think they can make dialogs, menus, text widgets, etc...
--
Jeremy Cowgar
http://jeremy.cowgar.com
