> I may be joining this hate group. I have the same
> wx Config Dick mentioned above...what does wxTrace do?
> A log trace somewhere might come in handy...I've
> succeded in generating a .sch that blows up EEschema
> reader without a hint of which file or line# it choked on.
> The trace back though
On 05/07/2012 01:25 PM, Dick Hollenbeck wrote:
full optionals seems to your phrase, I don't see it in the config.log or
$ ./configure --help | less
output. Please provide contents of your config.log so I can try and duplicate
it here and
see what command line options you are truly passing to
On 05/08/2012 09:00 AM, Lorenzo Marcantonio wrote:
> On Tue, May 08, 2012 at 08:21:50AM -0500, Dick Hollenbeck wrote:
>> Besides, it gives the computer something to do when it doesn't have anything
>> else to do,
>> which is most of the time.
> You didn't work with mainframes or embedded system it
On Tue, May 08, 2012 at 08:21:50AM -0500, Dick Hollenbeck wrote:
> Besides, it gives the computer something to do when it doesn't have anything
> else to do,
> which is most of the time.
You didn't work with mainframes or embedded system it seems XD
> Also, remember that you gain in most circums
On 05/08/2012 01:15 AM, Lorenzo Marcantonio wrote:
> On Tue, May 08, 2012 at 01:01:07AM -0500, Dick Hollenbeck wrote:
>> With latest wx, wxString is a container holding a std::string holding
>> characters encoded
>> as UTF8 bytes on linux and OSX. Windows is unknown.
> UTF8? not wide chars? Stran
On 8 May 2012 12:08, Marco Serantoni wrote:
> On Tue, May 8, 2012 at 8:01 AM, Dick Hollenbeck wrote:
>>
>>
>> This means that we eventually, we'll no longer need all the wxT() stuff,
>> since we
>> basically never put anything but ASCII characters in those wrappers and to
>> convert from an
>> AS
On Tue, May 8, 2012 at 8:01 AM, Dick Hollenbeck wrote:
>
> This means that we eventually, we'll no longer need all the wxT() stuff,
> since we
> basically never put anything but ASCII characters in those wrappers and to
> convert from an
> ASCII string to UTF8 is simply a matter of copying bytes
On Tue, May 08, 2012 at 01:01:07AM -0500, Dick Hollenbeck wrote:
> With latest wx, wxString is a container holding a std::string holding
> characters encoded
> as UTF8 bytes on linux and OSX. Windows is unknown.
UTF8? not wide chars? Strange, the C++ approach is usually using
wchar_t, not MBCS..
On 05/07/2012 11:10 PM, Lorenzo Marcantonio wrote:
> On Mon, May 07, 2012 at 02:25:44PM -0500, Dick Hollenbeck wrote:
>> But I cannot tell you what a wxChar* means THIS MONTH.
>>
>> The best thing the wxWidgets folks could do is to start with this line:
>>
>> typedef std::string wxString
>>
>> and
On Mon, May 07, 2012 at 02:25:44PM -0500, Dick Hollenbeck wrote:
> But I cannot tell you what a wxChar* means THIS MONTH.
>
> The best thing the wxWidgets folks could do is to start with this line:
>
> typedef std::string wxString
>
> and then go fix all the compile errors after that.
>
> wxStr
On 05/07/2012 12:23 PM, Lorenzo Marcantonio wrote:
> Trying to build with wx 2.9.3... it was configured 'full optionals'
>
> Now it seems that there is no more an implicit conversion from const wxString
> to wxChar*!
>
> Example: in displlst.cpp we have
>
> static int SortItems( const wxString& it
Trying to build with wx 2.9.3... it was configured 'full optionals'
Now it seems that there is no more an implicit conversion from const wxString
to wxChar*!
Example: in displlst.cpp we have
static int SortItems( const wxString& item1, const wxString& item2 )
{
return StrNumCmp( item1, item
12 matches
Mail list logo