cl@lgc.com (Cameron Laird) (04/19/91)
Two paragraphs of background: I still don't have a refined
X spirituality, or all the references I need (two distinct
items). Finding which functions, resources, and so on, are
standard, and which are not, constantly surprises me.
'Pologize if this is in the FAQ. I still haven't *seen* the
FAQ.
My question: how do I write
BOOL XmListPosSelected_p(listWidget, position)
Widget listWidget;
int position;
{
/* The entry is selected ... */
if (...)
return TRUE;
else
return FALSE;
}
? Here are my observations:
1. this is only significant for MULTIPLE_SELECT XmLists;
2. the only way I see to do this involves writing my own
handler, in some callback, to store away the current
state of the selections; but
3. this information *must* be available in some (lower-
level?) resources; it sure looks to me as though the
window manager knows which items are selected, and
which aren't.
Do you understand my question? Is there a clean way to
answer it? Is there a standard way?
--
Cameron Laird +1 713-579-4613
cl@lgc.com (cl%lgc.com@uunet.uu.net) +1 713-996-8546 klee@wsl.dec.com (Ken Lee) (04/19/91)
In article <1991Apr18.212904.21529@lgc.com>, cl@lgc.com (Cameron Laird) writes: |> My question: how do I write |> BOOL XmListPosSelected_p(listWidget, position) |> Widget listWidget; |> int position; |> { |> /* The entry is selected ... */ |> if (...) |> return TRUE; |> else |> return FALSE; |> } Check the XmNselectedItems resource and/or XmListGetSelectedPos() convenience function. -- Ken Lee DEC Western Software Laboratory, Palo Alto, Calif. Internet: klee@wsl.dec.com uucp: uunet!decwrl!klee
cl@lgc.com (Cameron Laird) (04/19/91)
In article <1991Apr18.150819@wsl.dec.com> klee@wsl.dec.com writes: >In article <1991Apr18.212904.21529@lgc.com>, cl@lgc.com (Cameron Laird) writes: >|> My question: how do I write >|> BOOL XmListPosSelected_p(listWidget, position) >|> Widget listWidget; >|> int position; >|> { >|> /* The entry is selected ... */ >|> if (...) >|> return TRUE; >|> else >|> return FALSE; >|> } > >Check the XmNselectedItems resource and/or XmListGetSelectedPos() >convenience function. . . . Thanks for the quick attention, Ken. It might interest you to know a bit more about what I'm doing: 1. XmNselectedItems: in fact, that's what I'm using now, but it's a problem, because some of my items have identical values. It can happen that my XmList shows string1 string2 string2 string4, the user selects the second "string2" (in position 3), and it is an error for me to treat this the same as if he or she had picked position 2; 2. XmListGetSelectedPos(): this is EXACTLY what I was seeking! What does it mean that it was so hard for me to find it in the re- ferences I have? Thanks again. You have improved products that real-world users will soon (I hope) see. -- Cameron Laird +1 713-579-4613 cl@lgc.com (cl%lgc.com@uunet.uu.net) +1 713-996-8546
cl@lgc.com (Cameron Laird) (04/19/91)
In article <1991Apr19.150134.22593@lgc.com> cl@lgc.com (Cameron Laird) writes: >In article <1991Apr18.150819@wsl.dec.com> klee@wsl.dec.com writes: >>In article <1991Apr18.212904.21529@lgc.com>, cl@lgc.com (Cameron Laird) writes: >>|> My question: how do I write >>|> BOOL XmListPosSelected_p(listWidget, position) >>|> Widget listWidget; >>|> int position; >>|> { >>|> /* The entry is selected ... */ >>|> if (...) >>|> return TRUE; >>|> else >>|> return FALSE; >>|> } . . . >2. XmListGetSelectedPos(): this is EXACTLY > what I was seeking! What does it mean that > it was so hard for me to find it in the re- > ferences I have? . . . I answer my own question: what it means is that I still have a poor grasp of the differences between 1.0 and 1.1. Sorry for the waste of bandwidth, folks. -- Cameron Laird +1 713-579-4613 cl@lgc.com (cl%lgc.com@uunet.uu.net) +1 713-996-8546
jfr@locus.com (Jon Rosen) (04/20/91)
In article <1991Apr19.150134.22593@lgc.com> cl@lgc.com (Cameron Laird) writes: > ><stuff deleted> > >2. XmListGetSelectedPos(): this is EXACTLY > what I was seeking! What does it mean that > it was so hard for me to find it in the re- > ferences I have? > It means the obvious... that the Motif reference manuals are (to put it tactfully) not the best examples of their ilk that exist ;-) ... Frankly (hope you OSF guys are listening), there is too much repetition and not enough simple explanation in the Motif reference (1.0 and 1.1) manual... They obviously got carried away by the use of computer editors because the same verbiage is repeated over and over and over again in a variety of widget definitions (sometimes even grammar errors are repeated identically in several places) (aside: sometimes it makes me wonder if computerized word processing has done a service or disservice to the world... before computerization, at least someone had to read every word of a book before it was published, i.e., the typesetter... these days, there are probably large parts of similar manuals and books where much of the book has not been read by anyone, not even the author)... I long for a simple list of every function in a widget class and what it does (the new X/Xt/Motif quick reference that comes with the new X11R4 books is not bad, by the way)... By the way, as long as I am flaming and on the topic of XmList, we are in the process of implementing an XmSortedList-type of class that will provide keeping an arbitrary blocks of data in user-defined order and displayable with user-defined captions in an XmList... I think that Motif is seriously deficient in not having a sorted XmList capability... Finally, the term "charset" used with XmStrings is extremely unclear to first time readers... It is quite obscure that "charset" in fact relates to the fonts defined in a font-list... This could be explained much better in the documentation... It took me a long time to realize that we could display items in XmLists in different fonts by simply changing the charset spec for each XmString... Finally finally, why is XmText so broken? In 1984, when Mac came out, its text manager was clearly primitive... it did not support multiple fonts, multiple type styles, tabs, etc... This was flamed over and over again in various Mac programmer journals and mags... In order to do fancy text editing (i.e., word processing, etc.), you had to implement your own text manager... Release 6.0 of Mac fixed this problem and the current text manager supports full attributing of substrings within text, tabs, etc... Release 6.0 came out for the Mac several years ago (actually before Motif 1.0 was formally released...) Why then didn't Motif do XmText right, if not in 1.0, at least in 1.1? Basically, we are saddled with the same problems that Mac programmers suffered with for 5 years but which were cured in 1989... (flames off..) Jon Rosen ========================================================= "Another birthday? Well, don't worry about getting old until you can't make sense out of the simplest things... ... isn't it?" -- from my favorite 40th birthday card =========================================================
don@atlantis.coral.com (Don Dewar) (04/22/91)
) Return-Path: <uunet!alfalfa.com!motif-request> ) To: jfr@prodnet.la.locus.com (Jon Rosen) ) Cc: motif@alfalfa.com ) Subject: Re: Is position n selected? ) In-Reply-To: <23654@oolong.la.locus.com> ) References: <1991Apr18.212904.21529@lgc.com>, <1991Apr18.150819@wsl.dec.com>, <1991Apr19.150134.22593@lgc.com>, <23654@oolong.la.locus.com> ) X-Mailer: Poste 1.0 B6 ) From: uunet!alfalfa.com!nazgul (Information Junkie) ) Date: Fri, 19 Apr 91 20:15:49 -0400 ) Encoding: 20 TEXT, 7 TEXT SIGNATURE ) ) > Frankly (hope you OSF guys are listening), there is too much repetition ) > and not enough simple explanation in the Motif reference (1.0 and 1.1) ) > manual... They obviously got carried away by the use of computer editors ) In fact I would skip the XmCreate calls. They all have the same signature ) and don't add any useful information. ) ) > I think that Motif is seriously deficient in not having a sorted ) > XmList capability... ) Sorted by what, in what language using what facilities? The only way ) to do this right is probably to add the ability to tuck a pointer in ) associated with each list item, and then be able to add one (or better ) yet, N) compare functions to the list to be used when items are added. ) I just layered that on top of the existing List. List has enough troubles ) right now without adding more functionality. ) ) As for XmText. Doing full international support is non-trivial, although ) the Mac does do it now. But OSF has nowhere near the resources that ) Apple has. I must say though, anyone who thinks that multi-font output, ) and support for multi-megabyte text (which the Mac does *not* do in their ) text edit widget) has to be slow should go use Apollo's Display Manager. ) ) Alfalfa Software, Inc. | Poste: The EMail for Unix ) nazgul@alfalfa.com | Send Anything... Anywhere ) 617/646-7703 (voice/fax) | info@alfalfa.com ) ) I'm not sure which upsets me more: that people are so unwilling to accept ) responsibility for their own actions, or that they are so eager to regulate ) everyone else's. ) ) I have to agree with this. Although we have implemented sorted lists in a set of specific instances in our application, it is not easy to do generally. Throw in international support and it becomes an exercise in futility. I think the diverse needs required in sorted lists, even for the simple cases, makes this a feature best left to the programmer on a case by case basis. +---------+ | Coral | |@@@@@*@**| |@@*@@**@@| Don Dewar |*@@**@@@@| Coral Network Corporation, Marlborough, MA |@***@@@@@| Internet: don@coral.com |@@**@@@@@| Phone: (508) 460-6010 |*********| Fax: (508) 481-6258 |Networks | +---------+
dbrooks@osf.org (04/22/91)
cl@lgc.com (Cameron Laird) writes: > Frankly (hope you OSF guys are listening), there is too much repetition > and not enough simple explanation in the Motif reference (1.0 and 1.1) > manual... Have you looked at the Programmer's Guide (ISBN 0-13-640673-4)? Conventionally, Guides and Reference Manuals exist in pairs and address different needs. David Brooks Systems Engineering Open Software Foundation