www.digitalmars.com         C & C++   DMDScript  

c++.stlsoft - Winstl controls library

reply "Pablo Aguilar" <paguilarg hotmail.com> writes:
I'm doing a little GUI work right now... and was looking at the 
combobox_gettext function...
Wouldn't it be better if it would return a proxy like c_str_ptr(HWND) does, 
instead of requiring a buffer?

I know c_str_ptr(HWND) will give me the text for a combobox using a proxy, 
but it'll only do it for the currently selected item, and I need to get the 
text for all of the items (in a loop), not just the selected one.

Just an idea...
Oct 14 2004
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
Can you give me a little pseudo-code for how this might work? I'm
unclear how you see it getting the separate items.

What would it do that you can't do with combobox_sequence?



"Pablo Aguilar" <paguilarg hotmail.com> wrote in message
news:ckmqr2$8ig$1 digitaldaemon.com...

 I'm doing a little GUI work right now... and was looking at the
 combobox_gettext function...
 Wouldn't it be better if it would return a proxy like c_str_ptr(HWND)


does,

 instead of requiring a buffer?

 I know c_str_ptr(HWND) will give me the text for a combobox using a


proxy,

 but it'll only do it for the currently selected item, and I need to


get the

 text for all of the items (in a loop), not just the selected one.

 Just an idea...
Oct 14 2004
parent reply "Pablo Aguilar" <paguilarg hotmail.com> writes:
Well, I figured it'd be as simple as:

for( int i=0; i != count; ++i )
{
    string item = combobox_gettext(combo, i);
}

The main differences with what's already available are:
1) I don't have to supply a buffer, since the proxy would do that for me 
(lik c_str_ptr, like I posted before)
2) I can't use combobox_sequence, because I want to work with item data 
(which is what my other posts about listbox/combobox functionals were about)

To clear things up a little...
I'm creating a dialog, which edits a list of possible labels for a given set 
of fields. That is, I have a combobox, representing the field I'm currently 
working with, and listbox with the possible labels for that field. I don't 
want to save anything 'till I hit "Apply", so I'm saving the entries in 
std::vector<string>'s. Now, the item data for each combobox is an 
std::vector<string>*. Finally, there's a small error checking routine, that 
warns the user of a label being defined for multiple fields; it's pretty 
much a word counting routine, only instead of adding #s of appearances by 
doing

std::map<string,int> m;
++m[label];

I'm storing the fields for which the string appears

std::map<string, std::vector<string> >  m;
m[label].push_back(field);

So I need to get the item data for each entry in the combobox, to get the 
vectors of strings, which is where label comes from, and field is the text 
for the item in the combobox.


 Can you give me a little pseudo-code for how this might work? I'm
 unclear how you see it getting the separate items.

 What would it do that you can't do with combobox_sequence?



 "Pablo Aguilar" <paguilarg hotmail.com> wrote in message
 news:ckmqr2$8ig$1 digitaldaemon.com...

 I'm doing a little GUI work right now... and was looking at the
 combobox_gettext function...
 Wouldn't it be better if it would return a proxy like c_str_ptr(HWND)


 does,

 instead of requiring a buffer?

 I know c_str_ptr(HWND) will give me the text for a combobox using a


 proxy,

 but it'll only do it for the currently selected item, and I need to


 get the

 text for all of the items (in a loop), not just the selected one.

 Just an idea...
Oct 15 2004
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
So you're not asking for some super-intuitive function that can get things from
your item data, you're just saying that 
you need to work from index, rather than dealing with the combo items as a
sequence?

This throws up two ideas:

1. combobox_gettext(), as you ask. Simple to do. I'll have a go later today.

2. a combobox enumerating class that returns combobox entries. The entry would
provide both text and item-data. The 
question would be whether it would get them when created, or just hold an index
and get them when asked. Hmmm...



"Pablo Aguilar" <paguilarg hotmail.com> wrote in message
news:ckp9n4$2j20$1 digitaldaemon.com...

 Well, I figured it'd be as simple as:

 for( int i=0; i != count; ++i )
 {
    string item = combobox_gettext(combo, i);
 }

 The main differences with what's already available are:
 1) I don't have to supply a buffer, since the proxy would do that for me (lik
c_str_ptr, like I posted before)
 2) I can't use combobox_sequence, because I want to work with item data (which
is what my other posts about 
 listbox/combobox functionals were about)

 To clear things up a little...
 I'm creating a dialog, which edits a list of possible labels for a given set
of fields. That is, I have a combobox, 
 representing the field I'm currently working with, and listbox with the
possible labels for that field. I don't want 
 to save anything 'till I hit "Apply", so I'm saving the entries in
std::vector<string>'s. Now, the item data for each 
 combobox is an std::vector<string>*. Finally, there's a small error checking
routine, that warns the user of a label 
 being defined for multiple fields; it's pretty much a word counting routine,
only instead of adding #s of appearances 
 by doing

 std::map<string,int> m;
 ++m[label];

 I'm storing the fields for which the string appears

 std::map<string, std::vector<string> >  m;
 m[label].push_back(field);

 So I need to get the item data for each entry in the combobox, to get the
vectors of strings, which is where label 
 comes from, and field is the text for the item in the combobox.


 Can you give me a little pseudo-code for how this might work? I'm
 unclear how you see it getting the separate items.

 What would it do that you can't do with combobox_sequence?



 "Pablo Aguilar" <paguilarg hotmail.com> wrote in message
 news:ckmqr2$8ig$1 digitaldaemon.com...

 I'm doing a little GUI work right now... and was looking at the
 combobox_gettext function...
 Wouldn't it be better if it would return a proxy like c_str_ptr(HWND)


 does,

 instead of requiring a buffer?

 I know c_str_ptr(HWND) will give me the text for a combobox using a


 proxy,

 but it'll only do it for the currently selected item, and I need to


 get the

 text for all of the items (in a loop), not just the selected one.

 Just an idea...
Oct 15 2004
parent reply "Pablo Aguilar" <paguilarg hotmail.com> writes:
 So you're not asking for some super-intuitive function that can get things 
 from your item data, you're just saying that
 you need to work from index, rather than dealing with the combo items as a 
 sequence?

 This throws up two ideas:

 1. combobox_gettext(), as you ask. Simple to do. I'll have a go later 
 today.

 2. a combobox enumerating class that returns combobox entries. The entry 
 would provide both text and item-data. The question would be whether it 
 would get them when created, or just hold an index and get them when 
 asked. Hmmm...


That pretty much covers it, I think (along with the same functionality for 
listboxes, or even listviews, having their item-data be the list item's 
LPARAM)
Oct 15 2004
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Pablo Aguilar" <paguilarg hotmail.com> wrote in message
news:ckpgns$2oii$1 digitaldaemon.com...

 So you're not asking for some super-intuitive function that can get things
from your item data, you're just saying 
 that
 you need to work from index, rather than dealing with the combo items as a
sequence?

 This throws up two ideas:

 1. combobox_gettext(), as you ask. Simple to do. I'll have a go later today.

 2. a combobox enumerating class that returns combobox entries. The entry would
provide both text and item-data. The 
 question would be whether it would get them when created, or just hold an
index and get them when asked. Hmmm...


 That pretty much covers it, I think (along with the same functionality for
listboxes, or even listviews, having their 
 item-data be the list item's LPARAM)


This one's stayed 'Unread' in my newsreader for too long, as I've now forgotten
the context. Do you still want this 
functionality? Can you (re-)explain your requirement?

Cheers

Matthew
May 26 2005
parent reply "Pablo Aguilar" <paguilarg hotmail.com> writes:
 This one's stayed 'Unread' in my newsreader for too long, as I've now 
 forgotten the context. Do you still want this functionality? Can you 
 (re-)explain your requirement?


It is not an top priority of mine, but I still believe having it would be 
nice. Here's a re-explanation of it:

ListBoxes, ComboBoxes and ListViews, have a way to store data (DWORD, DWORD 
and LPARAM types respectively) along with each item they contain, and 
guarantee that the data will remain correctly paired, no matter how the 
items get sorted or moved around later.

You currently have listbox_sequence, combobox_sequence, and 
listview_sequence, which's purpose I need not explain.

My request was to give each of those sequence classes the ability to iterate 
their items, but have the value returned by their iterator's operator*, be 
something like std::map's, namely a pair made up of the text and value of a 
given item in the sequence.

I used to use this (and my [not so] old code still does) to store, for 
example, a pointers to objects, which are represented by entries in lists. 
So I could do something like (in MFC code):

void fn()
{
    int i = list.GetCurSel();
    Object* p = reinterpret_cast<Object*>(list.GetItemDataPtr(i));
}

thus saving me the lookup I'd otherwise need to do by first fetching the 
text and then doing a lookup in my own data structures.

With the enhancement I mention, you'd be able to do something like:

void fn()
{
    // I know the syntax below won't work with some compilers (i.e. VC), but 
you get the point...
    for(
        X_sequence::const_iterator it = list.begin<Object*>()
        , end = list.end();
        ; it != end
        ; ++it
    )
    {
        // maybe .text and .value might be better names, I'm just following 
map's lead here
        string text = (*it).first;
        Object* p = (*it).second;
    }

    // where the alternative is to iterate this manually with indexes and 
GetItemData[Ptr] for MFC or XB_GETITEMDATA (and uglier for ListView)
}

Interesting things might be accomplished using also your select_2nd helper.

Anyway, I say used to, because with the coming of Win64, I'm no longer 
certain the size available for item data will be enough to store pointers.


 Cheers

 Matthew


Pablo
May 26 2005
parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"Pablo Aguilar" <paguilarg hotmail.com> wrote in message
news:d754e4$2tvq$1 digitaldaemon.com...

 This one's stayed 'Unread' in my newsreader for too long, as I've now
forgotten the context. Do you still want this 
 functionality? Can you (re-)explain your requirement?


 It is not an top priority of mine, but I still believe having it would be
nice. Here's a re-explanation of it:

 ListBoxes, ComboBoxes and ListViews, have a way to store data (DWORD, DWORD
and LPARAM types respectively) along with 
 each item they contain, and guarantee that the data will remain correctly
paired, no matter how the items get sorted 
 or moved around later.

 You currently have listbox_sequence, combobox_sequence, and listview_sequence,
which's purpose I need not explain.

 My request was to give each of those sequence classes the ability to iterate
their items, but have the value returned 
 by their iterator's operator*, be something like std::map's, namely a pair
made up of the text and value of a given 
 item in the sequence.

 I used to use this (and my [not so] old code still does) to store, for
example, a pointers to objects, which are 
 represented by entries in lists. So I could do something like (in MFC code):

 void fn()
 {
    int i = list.GetCurSel();
    Object* p = reinterpret_cast<Object*>(list.GetItemDataPtr(i));
 }

 thus saving me the lookup I'd otherwise need to do by first fetching the text
and then doing a lookup in my own data 
 structures.

 With the enhancement I mention, you'd be able to do something like:

 void fn()
 {
    // I know the syntax below won't work with some compilers (i.e. VC), but
you get the point...
    for(
        X_sequence::const_iterator it = list.begin<Object*>()
        , end = list.end();
        ; it != end
        ; ++it
    )
    {
        // maybe .text and .value might be better names, I'm just following
map's lead here
        string text = (*it).first;
        Object* p = (*it).second;
    }

    // where the alternative is to iterate this manually with indexes and
GetItemData[Ptr] for MFC or XB_GETITEMDATA 
 (and uglier for ListView)
 }

 Interesting things might be accomplished using also your select_2nd helper.

 Anyway, I say used to, because with the coming of Win64, I'm no longer certain
the size available for item data will 
 be enough to store pointers.


 Cheers

 Matthew


 Pablo


Yes, I see where you're coming from. I think a policy-based mechanism, such
that one could specify text, or value (<T>), 
or pair<text, T>. That way the listbox_sequence and listbox_data_sequence
classes would just be typedefs

Let me think about it ...
May 27 2005