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...

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...
>
>

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...
>>
>>
>
> 

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...
>>>
>>>
>>
>>
>
> 

> 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)

"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

> 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

"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 ...