> Actually, I was thinknig of it getting the selected item's text, or null
(or
> "", whatever) if nothing was selected,

Ah, that's an interesting spin. Maybe that would be a go-er

>of course this wouldn't work with
> multiple selection lists, but then the shim with an index you mentioned kicks in (when you know there might be multiple selections)

Yes, I think that's the way to go.

> Did you get a chance to look at the clipboard stuff I posted last week?

I've looked at it, and am confident that it looks suitable (once we've minimised a few dependencies and such). Be assured that I won't forget about it. But I am trying desparately to get some final bits of my book done this week, while I'm trying to shake off the jetlag from having travelled to the UK from Australia for a holiday (!).

At this point, it looks like 1.7.1 will happen in about 3 weeks. I'll *definitely* contact you some time before then about the clipboard, and I'll also post the new shims (which I might do in a day or so).

Cheers

Matthew

>
> "Matthew" <matthew@stlsoft.org> wrote in message news:c2mv10$ch3$1@digitaldaemon.com...
> > Hi Pablo
> >
> > The c_str_ptr shim boils down to a call to GetWindowText(). Since the contents of a listbox are not stored in the window text, c_str_ptr will
> not
> > yield the list box contents. In any case, which one would it return?
> >
> > However, you've got me thinking now, and maybe I might add a shim that
> takes
> > an object and an index. This could work for list/combo boxes, list
views,
> as
> > well as completely different types, such as stl containers, COM
> collections,
> > etc.
> >
> > It's funny. I've never considered shims having more than one parameter,
> but
> > there's no reason why they can't.
> >
> > I'm busy this week, but maybe next week I can add this in, in time for 1.7.1.
> >
> > Cheers
> >
> > Matthew
>
>

Pablo

I've done a first stab. Unfortunately, it's on the laptop I've borrowed (from my brother-in-law) which is currently not networked to this borrowed (from my mum) desktop. I thought I would be able to pass them across using CD-RWs, but one is using Roxio, and the other is using Pinnacle's InstantCD/DVD, and it doesn't work. Ah, you got to love hardware!!

Anyway, I should have it sorted in the next day or so, and then I'll post it here, or will do another beta.

Thanks for the idea. If you have any further refinements you want to suggest once you've tried it out, please let me know.

btw, I've recently updated *all* STLSoft c_str_ptr*() shims to be IOStream
compatible, i.e. to work with operator <<().

Cheers

Matthew



"Pablo Aguilar" <paguilarg@hotmail.com> wrote in message news:c2nnpl$1rnm$1@digitaldaemon.com...
> Actually, I was thinknig of it getting the selected item's text, or null
(or
> "", whatever) if nothing was selected, of course this wouldn't work with multiple selection lists, but then the shim with an index you mentioned kicks in (when you know there might be multiple selections)
>
> Did you get a chance to look at the clipboard stuff I posted last week?
>
> "Matthew" <matthew@stlsoft.org> wrote in message news:c2mv10$ch3$1@digitaldaemon.com...
> > Hi Pablo
> >
> > The c_str_ptr shim boils down to a call to GetWindowText(). Since the contents of a listbox are not stored in the window text, c_str_ptr will
> not
> > yield the list box contents. In any case, which one would it return?
> >
> > However, you've got me thinking now, and maybe I might add a shim that
> takes
> > an object and an index. This could work for list/combo boxes, list
views,
> as
> > well as completely different types, such as stl containers, COM
> collections,
> > etc.
> >
> > It's funny. I've never considered shims having more than one parameter,
> but
> > there's no reason why they can't.
> >
> > I'm busy this week, but maybe next week I can add this in, in time for 1.7.1.
> >
> > Cheers
> >
> > Matthew
>
>

> > Actually, I was thinknig of it getting the selected item's text, or null
> (or
> > "", whatever) if nothing was selected,
>
> Ah, that's an interesting spin. Maybe that would be a go-er
>
> >of course this wouldn't work with
> > multiple selection lists, but then the shim with an index you mentioned kicks in (when you know there might be multiple selections)
>
> Yes, I think that's the way to go.

Great...

One comment though, this would work with a known type window (CListBox, CComboBox, etc), but wouldn't in case you've got a plain HWND, I've got another small routine (which is buggier I'm sure) which doesn't quite go with your 'lightweight' philosophy, so I didn't bother mentioning it... anyway, it does take a plain HWND and get's its text, by cheking (with GetWindowClass) if it's of a know class and use specific behavior for it, or default to using GetWindowText if it isn't...

I say it isn't lightweight, 'cuz it has to check and resort to various if/else constructs, but I'll leave that critique to you... here's the attachment anyway

> > Did you get a chance to look at the clipboard stuff I posted last week?
>
> I've looked at it, and am confident that it looks suitable (once we've minimised a few dependencies and such). Be assured that I won't forget
about
> it. But I am trying desparately to get some final bits of my book done
this
> week, while I'm trying to shake off the jetlag from having travelled to
the
> UK from Australia for a holiday (!).
>
> At this point, it looks like 1.7.1 will happen in about 3 weeks. I'll *definitely* contact you some time before then about the clipboard, and
I'll
> also post the new shims (which I might do in a day or so).

I guess it's pretty straight forward to remove some dependencies (at least if it's noncopyable we're talking about), but I'll wait to hear all of your comments...

> Cheers
>
> Matthew

> Pablo
>
> I've done a first stab. Unfortunately, it's on the laptop I've borrowed (from my brother-in-law) which is currently not networked to this borrowed (from my mum) desktop. I thought I would be able to pass them across using CD-RWs, but one is using Roxio, and the other is using Pinnacle's InstantCD/DVD, and it doesn't work. Ah, you got to love hardware!!

I bet you actually enjoyed writing that...

> Anyway, I should have it sorted in the next day or so, and then I'll post
it
> here, or will do another beta.
>
> Thanks for the idea. If you have any further refinements you want to
suggest
> once you've tried it out, please let me know.

I will, worry not, I do a lot of MFC gui stuff, so I've got plenty of code to test with...

> btw, I've recently updated *all* STLSoft c_str_ptr*() shims to be IOStream
> compatible, i.e. to work with operator <<().
>
> Cheers
>
> Matthew

"Pablo Aguilar" <paguilarg@hotmail.com> wrote in message news:c2oe41$3pu$1@digitaldaemon.com...
> > > Actually, I was thinknig of it getting the selected item's text, or
null
> > (or
> > > "", whatever) if nothing was selected,
> >
> > Ah, that's an interesting spin. Maybe that would be a go-er
> >
> > >of course this wouldn't work with
> > > multiple selection lists, but then the shim with an index you
mentioned
> > > kicks in (when you know there might be multiple selections)
> >
> > Yes, I think that's the way to go.
>
> Great...
>
> One comment though, this would work with a known type window (CListBox, CComboBox, etc), but wouldn't in case you've got a plain HWND, I've got another small routine (which is buggier I'm sure) which doesn't quite go with your 'lightweight' philosophy, so I didn't bother mentioning it... anyway, it does take a plain HWND and get's its text, by cheking (with GetWindowClass) if it's of a know class and use specific behavior for it,
or
> default to using GetWindowText if it isn't...
>
> I say it isn't lightweight, 'cuz it has to check and resort to various if/else constructs, but I'll leave that critique to you... here's the attachment anyway

That's the general technique I've just used to adjust WinSTL's c_str_ptr*() shims to work with ListBox. Currently it uses a hard-coded helper function which searches through a list of Window types, and returns an enum value. I plan to make a customisable version at some point, once the basic technique has been tested (by you!).

(btw, unfortunately I cannot look at any newsgroup attachments on this machine, as OE "helpfully" removes them. Can you forward it to by email. If not, not to worry, since it sounds like we're working on the same basic technique.)

>
> > > Did you get a chance to look at the clipboard stuff I posted last
week?
> >
> > I've looked at it, and am confident that it looks suitable (once we've minimised a few dependencies and such). Be assured that I won't forget
> about
> > it. But I am trying desparately to get some final bits of my book done
> this
> > week, while I'm trying to shake off the jetlag from having travelled to
> the
> > UK from Australia for a holiday (!).
> >
> > At this point, it looks like 1.7.1 will happen in about 3 weeks. I'll *definitely* contact you some time before then about the clipboard, and
> I'll
> > also post the new shims (which I might do in a day or so).
>
> I guess it's pretty straight forward to remove some dependencies (at least if it's noncopyable we're talking about), but I'll wait to hear all of
your
> comments...
>
> > Cheers
> >
> > Matthew
>
>
>
>

> > Pablo
> >
> > I've done a first stab. Unfortunately, it's on the laptop I've borrowed (from my brother-in-law) which is currently not networked to this
borrowed
> > (from my mum) desktop. I thought I would be able to pass them across
using
> > CD-RWs, but one is using Roxio, and the other is using Pinnacle's InstantCD/DVD, and it doesn't work. Ah, you got to love hardware!!
>
> I bet you actually enjoyed writing that...

Hmmm. Options were:

1. Try and do these last couple of chapter revisions
2. Go to bed and try to sleep but stay awake worrying about having to do
these last couple of chapter revisions
3. Stay up for an hour and do some fun coding.


> > Anyway, I should have it sorted in the next day or so, and then I'll
post
> it
> > here, or will do another beta.
> >
> > Thanks for the idea. If you have any further refinements you want to
> suggest
> > once you've tried it out, please let me know.
>
> I will, worry not, I do a lot of MFC gui stuff, so I've got plenty of code to test with...

Cool. In fact, we can do overloads for MFC which will be efficient, since they won't need to do tests because they can assume certain natures. I will also do this, but not at the moment.

I managed to get the damnable CD-RW to be read, by rebooting, which I had to do because OE froze. :)

So here it is, in *barely* tested form.

> > btw, I've recently updated *all* STLSoft c_str_ptr*() shims to be
IOStream
> > compatible, i.e. to work with operator <<().
> >
> > Cheers
> >
> > Matthew

> > > I've done a first stab. Unfortunately, it's on the laptop I've
borrowed
> > > (from my brother-in-law) which is currently not networked to this
> borrowed
> > > (from my mum) desktop. I thought I would be able to pass them across
> using
> > > CD-RWs, but one is using Roxio, and the other is using Pinnacle's InstantCD/DVD, and it doesn't work. Ah, you got to love hardware!!
> >
> > I bet you actually enjoyed writing that...
>
> Hmmm. Options were:
>
> 1. Try and do these last couple of chapter revisions
> 2. Go to bed and try to sleep but stay awake worrying about having to do
> these last couple of chapter revisions
> 3. Stay up for an hour and do some fun coding.

Actually, I was talking about the rant...
Good choice, though... do you have to make it often?

> > > Anyway, I should have it sorted in the next day or so, and then I'll
> post
> > it
> > > here, or will do another beta.
> > >
> > > Thanks for the idea. If you have any further refinements you want to
> > suggest
> > > once you've tried it out, please let me know.
> >
> > I will, worry not, I do a lot of MFC gui stuff, so I've got plenty of
code
> > to test with...
>
> Cool. In fact, we can do overloads for MFC which will be efficient, since they won't need to do tests because they can assume certain natures. I
will
> also do this, but not at the moment.

Well, this is what I thought you'd do first...

> I managed to get the damnable CD-RW to be read, by rebooting, which I had
to
> do because OE froze. :)
>
> So here it is, in *barely* tested form.
>
> > > btw, I've recently updated *all* STLSoft c_str_ptr*() shims to be
> IOStream
> > > compatible, i.e. to work with operator <<().
> > >
> > > Cheers
> > >
> > > Matthew

I'll start using 'em right away... and let you know any comments/complaints...

btw, here's the code for the attachment you couldn't see:
#ifndef __WNDTOSTR_H__INCLUDED__
#define __WNDTOSTR_H__INCLUDED__

namespace WndToStr_Imp {
 template<typename E> HWND& get_into(HWND& w, std::basic_string<E>& s)
 {
  int len = GetWindowTextLength(w);
  if( (len != 0) && (len != -1) )
  {
   s.resize(len);
   GetWindowText(w, &s[0], len+1);
  }
  else
   s.erase();

  return w;
 }
}

template<typename E> HWND &operator>>(HWND &w, std::basic_string<E> &s)
{
 char class_name[20];
 GetClassName(w, class_name, sizeof(class_name)-1);
 unsigned msg_idx = NULL, msg_len, msg_get;

 if( !stricmp(class_name, "LISTBOX") )
 {
  msg_idx = LB_GETCURSEL;
  msg_len = LB_GETTEXTLEN;
  msg_get = LB_GETTEXT;
 }
 else if( !stricmp(class_name, "COMBOBOX") )
 {
  msg_idx = CB_GETCURSEL;
  msg_len = CB_GETLBTEXTLEN;
  msg_get = CB_GETLBTEXT;

  long style = GetWindowLong(w, GWL_STYLE);
  if( !((style & CBS_DROPDOWNLIST) == CBS_DROPDOWNLIST) )
   msg_idx = NULL;
 }

 int idx = (msg_idx == NULL)
  ? -1
  : SendMessage(w, msg_idx, 0, 0);

 if( idx != -1 )
 {
  int len = SendMessage(w, msg_len, idx, 0);
  if( len )
  {
   s.resize(len);
   SendMessage(w, msg_get, idx, (LPARAM)&s[0]);
  }
  else
   s.erase();
 }
 else
  WndToStr_Imp::get_into(w, s);

 return w;
}

#endif /* __WNDTOSTR_H__INCLUDED__ */

Got something:
you ether forgot to attach stlsoft_auto_buffer.h or winstl_windows_ident.h's
trying to do something wrong with

auto_buffer<...>::internal_size and auto_buffer<...>::resize

Doh!

Hopefully this makes it work. If not, I may have to do another beta very soon.

Cheers

Matthew

"Pablo Aguilar" <paguilarg@hotmail.com> wrote in message news:c2ogk7$83m$1@digitaldaemon.com...
> Got something:
> you ether forgot to attach stlsoft_auto_buffer.h or
winstl_windows_ident.h's
> trying to do something wrong with
>
> auto_buffer<...>::internal_size and auto_buffer<...>::resize
>
>

If anyone would be interested in putting there C++, STL, Unix and Kernel skills to use in return for £75k package then please call Charlie on 01273 200300 to find out more.


In article <c01k16$8sf$1@digitaldaemon.com>, Matthew says...
>
>Hi everyone
>
>[First, apologies to any D folks who do not use, and aren't interested in, C++/STL/STLSoft. It's just that there are so many good ideas in there, that I wanted to snag any that might be transferable over to STLSoft.]
>
>STLSoft v1.7.1 will be released within the next 4-6 weeks, and it's the last chance for getting in any feature requests. Available now from the STLSoft main site - http://stlsoft.org/ - is STLSoft v1.7.1 beta 3 (stlsoft_1_7_1_beta3.zip), containing much of what will constitute the final 1.7.1 release.
>
>To whet your appetite, I'm including a list of additions and a list of changes to the libraries at the end of this post. Many of these appear in my book "Imperfect C++" which will be out later in the year.
>
>As yet, the documentation has not had any new work. I'd *really* appreciate any suggestions for improvements for the documentation, as I know it's the Achilles' Heel of the project. From the feedback I've had, this is the only area of the libraries that is putting people off from using them more. If anyone wants to volunteer to help out on this, it'd be fantastic. (Sounds of thousands of people taking a step back ...)
>
>Thanks for listening. Please feel free to post any questions via the FAQ website (http://stlsoft.gregpeet.com/).
>
>Cheers (changes & additions follow below:)
>
>Matthew Wilson
>
>Director, Synesis Software
>    (www.synesis.com.au)
>STLSoft moderator
>    (http://www.stlsoft.org)
>Contributing editor, C/C++ Users Journal
>    (www.synesis.com.au/articles.html#columns)
>
>-----------------------------------------------------
>
>
>
>ADDITIONS
>==========
>
>The additions to the libraries are as follows:
>
>  General
>    Many of the standard-offending symbols with leading underscores have
>been changed. I intend to do the rest before the final release
>
>
>  Compilers
>    Intel 8.0
>    CodePlay VectorC 2.06
>    Comeau 4.3.3. (not quite complete yet, though ;))
>    GCC v3+ now supported for COMSTL
>
>  STLSoft (v1.6.5 => 1.7.1)
>    array_proxy template class - type-safe & size-safe aid for passing
>arrays of object types to functions. Controls passing of derived arrays in a safe manner
>    explicit_cast template class - implements explicit conversion operators
>    fast_string_concatenator template class - a helper class for
>implementing fast, non-intrusive, string concatenation (Featured in Imperfect C++, and in the article "Fast, Non-Intrusive String Concatenation" in April's CUJ)
>    basic_fixed_substring template class - provides a non-resizable "view"
>onto a part of an existing string, useful for high efficiency string manipulation
>    literal_cast template class - used to provide type-to-range validation
>of literal constants
>    Meta Programming Constructs - including is_pointer_type<>,
>is_array_type<>, is_convertible_to_bool<>, is_numeric_type<>, is_integral_type<>, is_bool_type<>, is_void_type<>, is_fundamental_type<>, is_compound_type<>, is_class_type<>, is_const<>, is_volatile<>, (void-able) size_of<>, is_same_type<>, has_value_type<>, has_iterator<>, has_const_iterator<>
>    pod_vector template class - highly efficient vector for POD types (only)
>    proxy_sequence template class - highly efficient pseudo-sequence, for
>layering on top of arrays with providing parameterisable value_type.
>    Size Traits - providing type-definitions of signed and unsigned types of
>a corresponding bit-size
>    Type Traits - for a given type: providing is_pointer, is_reference,
>is_const and is_volatile attributes; defining two pointer/reference-stripped
>types: the base_type (non-cv-qualified) and cv_type (cv-qualifiers retained)
>    unused_return_value_monitor template class - used for detecting when a
>potentially expensive return value is not used; ideal for post-increment operators; has parameterisable "failure" policy
>
>    stlsoft.h: STLSOFT_DECLARE_TEMPLATE_PARAM_AS_FRIEND(),
>STLSOFT_SUPPRESS_UNUSED()
>
>  ATLSTL (v1.2.8 => 1.3.1)
>    ccombstr_veneer template adaptor class     - makes CComBSTR conformant
>to the STL String concept
>    SupportErrorInfoImpl / SupportErrorInfoImpl2 / SupportErrorInfoImpl3
>template classes - simple ATL template that provides ISupportErrorInfo implementation
>
>  COMSTL (v1.2.5 => 1.4.1)
>    collection_sequence template class - maps COM Collections to STL-like
>sequence
>    set_error_info() function - sets the calling thread's error-info for a
>given description string
>    interface_ptr template class - smart-enough interface pointer class
>
>  MFCSTL (v1.3.4 => 1.3.5)
>    no additions
>
>  UNIXSTL (v1.0.3 => 1.1.1)
>    basic_current_directory template class - provides access to current
>directory in string form
>    basic_environment_variable template class - provides access to a given
>environment value in string form
>    compare_path template function object - compares file-system paths via
>fully-qualified path form
>    process_mutex class
>    spin_mutex class
>    thread_mutex class
>
>  WinSTL (v1.3.7 => 1.4.1)
>    acl_sequence class - provides STL-like sequence semantics over Access
>Control Lists
>    Atomic Functions - a suite of functions that provide optimal performance
>for single-processor/SMP/mixed Intel processors using inline assembler
>    clipboard_format_sequence class - provides STL-like sequence semantics
>over the system's supported clipboard formats
>    basic_error_desc template class - provides access to the string form of
>a given Win32 Error Code
>    last_error_scope - provides scoping of last error code, for maintaining
>correct state when doing intermediate error processing
>    event class - a thin wrapper for the Win32 event kernel synchronisation
>kernel object
>    listview_sequence class - provides STL-like sequence semantics over the
>items in a ListView common control
>    basic_module_directory template class - provides access to a given (or
>the calling process's) module's directory
>    process_mutex class
>    setcursor_scope class - provides scoping of the cursor
>    setfocus_scope class - provides scoping of the window with the focus
>    Time Functions - functions to convert between time_t and FILETIME
>    token_information template class - type-safe, resource-managed accessor
>class to token information (via GetTokenInformation())
>    window_text_scope template class - provides scoping of a window's text
>
>CHANGES
>========
>
>The changes to the libraries are as follows:
>
>  STLSoft (v1.6.5 => 1.7.1)
>    auto_buffer - it's now resizable, without any loss of efficiency. This
>supports the new pod_vector template class
>    minor rationalisations to char_traits
>    Renaming of constraits: has_base => must_have_base, is_veneer =>
>must_be_same_size, type_is_non_class_or_trivial_class => must_be_pod
>    fixed_array_d1/2d/3d/4d template classes - improved efficiency, by using
>an additional template parameter to determine, at compile-time, whether slices "own" their memory; previously this was achieved at runtme by a member variable
>    frame_array_1d/2d/3d/4d renamed to static_array_1d/2d/3d/4d
>    frame_string: bug fixes
>    sign_traits: bug fixes; addition of "bytes" member value
>    simple_string: bug fixes; improvements in performance
>
>  ATLSTL (v1.2.8 => 1.3.1)
>
>  COMSTL (v1.2.5 => 1.4.1)
>    simplification of interface_cast; addition of interface_cast_test
>    enum_sequence - this has simplified, and now only has three non-default
>parameters for the template
>
>  MFCSTL (v1.3.4 => 1.3.5)
>    minor enhancements to cstring_veneer
>
>  UNIXSTL (v1.0.3 => 1.1.1)
>    findfile_sequence renamed to glob_sequence (findfile_sequence is
>retained for backwards compatibility)
>    tls_index renamed to tss_index (tls_index is retained for backwards
>compatibility)
>    filesystem_traits: lots of new features
>    readdir_sequence: now supports flags "includeDots", "directories" and
>"files"
>
>  WinSTL (v1.3.7 => 1.4.1)
>    ansi2Unicode & unicode2Ansi templates now have a second ctor which takes
>a length
>    filesystem_traits: addition of file_exists() method
>    findfile_sequence now correctly implements InputIterator semantics, and
>works correctly when iterators incremented in both prefix and postfix forms
>    findvolume_sequence: same as for findfile_sequence
>    performance_counter_init renamed to performance_counter_initialiser
>
>
>
>
>
>