Re: [gtkmm] Problem with g_io_channel_read_chars

Am Fre, 2002-06-07 um 10.41 schrieb Andrew E. Makeev:

> Yes, you're right, there is nothing wrong with gtkmm, glibmm stuff.
> Only one thing I would to ask about:
>     show me an example, please, how to use streams to receive/send data
> from/to
>     sockets,

There is no standardized UNIX file I/O support in the STL, but's fairly
easy to implement your own stream buffer for that.  Josuttis even has an
example in his book "The C++ Standard Library".

and is there glibmm wrapping for g_io_channel_<> functions?

No, at least not yet.  I'm unsure whether they should be wrapped.  If at
all, I'll wrap them as STL stream buffer.

> I've replaced that with:
>     rsize = recv (m_FileDescriptor, buffer, sizeof(buffer), 0);
> then got following error when tried to assign buffer to Glib::ustring:
> (testtcp:25914): glibmm-CRITICAL **:
> unhandled exception (type Glib::Error) in signal handler:
> domain: g_convert_error
> code  : 1
> what  : Invalid byte sequence in conversion input

This message means a Glib::ConvertError was thrown but never caught in
the current signal handler (you can't propagate exceptions through C
callbacks).  You can catch Glib::ConvertError -- the critical warning
just tells you what to catch.

However, I doubt this exception occurred because you assigned something
to a Glib::ustring.  The data you assign to Glib::ustring is assumed to
be UTF-8 encoded, so no checking is performed.  You aren't using
operator<<() or Glib::convert(), by any chance?

What you have to do is something like:

Glib::ustring foo = Glib::convert(bar, "UTF-8", "KOI8-R");

> Looks like glib couldn't convert some of received data (russian koi8-r
> symbols and control sequences) to internal Glib::ustring data format... What
> is the way to let g_io_channel_read_<whatever> to drop control sequences
> (that I am receiving when starting a telnet session) and convert
> International symbols properly?

I don't think the control sequences are your problem, since they're
ASCII compatible, IIRC.

> (g_io_channel_get_encoding() on my channel returns UTF-8 as should)

It should not.  It should rather be "koi8-r".  Glib cannot guess the
encoding to read.

> Well, it will be a shame to parse received data myself to drop those symbols
> that made glib CRITICAL ;(.

There was nothing critical in glib or glibmm.  The critical thing is
that you didn't catch an exception, as you should.  Anyway, the
exception probably occurred because you're doing something wrong in your


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]