Will wxWidgets 2.5.4 have a working WxWinCE ??
-
ABX
- Can't get richer than this
- Posts: 810
- Joined: Mon Sep 06, 2004 1:43 pm
- Location: Poznan, Poland
- Contact:
Re: Will wxWidgets 2.5.4 have a working WxWinCE ??
"working" is very wide termedrin wrote:see topic
You probably mean whether it will fix your particular problem you find with 2.5.3. That's hard to answer with lack of knowledge about your problems.Basically my answer is: since 2.5.3 worked fine for some of the persons I do not think that 2.5.4 will be worse and I hope it will be just better
10 hours ago I builded CVS code for 2.5.4 with eVC3 and Julian Smart builded it for eVC4 and it seems to work. But there are many targets available on the market so it is close to impossible to assure you about 100% of "working" you asking for.
There were a few talks about wxWinCE support in mailing lists. Try to browse recent posts at http://lists.wxwidgets.org/ for some more informations.
ABX
CVS Head, 2.8.X
wxMSW, wxWinCE, wxPalmOS, wxOS2, wxMGL, bakefile
gcc 3.2.3, bcc 5.51, dmc 8.48, ow 1.6, vc 7.1, evc 3/4, pods 1.2
wxMSW, wxWinCE, wxPalmOS, wxOS2, wxMGL, bakefile
gcc 3.2.3, bcc 5.51, dmc 8.48, ow 1.6, vc 7.1, evc 3/4, pods 1.2
-
ABX
- Can't get richer than this
- Posts: 810
- Joined: Mon Sep 06, 2004 1:43 pm
- Location: Poznan, Poland
- Contact:
You did not disturbed at all. I'm very interested in having wxWinCE port mature. It still seem to have some problems with missing features or not supported targets but sometimes also due to different development tools and small base of experienced users or some problems are due to not understanding some concepts. So if the build fails for you please report it so other could do one of:edrin wrote:Sorry to disturbe you
- point you wrong assumption
- point you way of fixing
- take your report and fix.
Your are best placed to debug your problem and make this cooperative work better. Thanks in advance!
ABX
CVS Head, 2.8.X
wxMSW, wxWinCE, wxPalmOS, wxOS2, wxMGL, bakefile
gcc 3.2.3, bcc 5.51, dmc 8.48, ow 1.6, vc 7.1, evc 3/4, pods 1.2
wxMSW, wxWinCE, wxPalmOS, wxOS2, wxMGL, bakefile
gcc 3.2.3, bcc 5.51, dmc 8.48, ow 1.6, vc 7.1, evc 3/4, pods 1.2
Hi!
From my point of view 2.5.3 compiled with eVC 4 is already stable and works perfectly for my targets (currently only the emulator and a Pocket LOOX). The major problem of the Windows CE port, as ABX pointed out, is, that the compiler lacks some features the "normal" Win32 API supports. Some of these lackings have been fixed by simply adding new source files (like for time.cpp) and make unknown functions known (not really working though) in order to compile the lib.
With 2.5.4 things can only get better. I released two patches recently that made it to CVS (socket support and wxDateTime::Format()), that didn't work before, because of the platform not supporting some needed functions. The file API could need some testing, too. I experienced some problems with simple stuff like wxGetTempFileName(). Looking at the code I think that most errors can be fixed by #ifdefing the sources a little more. It just takes some more time until every error has been found.
As ABX said: If you use it, it's best to use a debug version. You'll find some errors and you'll normally be able to fix it. In that case: Patch it and release the patch so things get better
From my point of view 2.5.3 compiled with eVC 4 is already stable and works perfectly for my targets (currently only the emulator and a Pocket LOOX). The major problem of the Windows CE port, as ABX pointed out, is, that the compiler lacks some features the "normal" Win32 API supports. Some of these lackings have been fixed by simply adding new source files (like for time.cpp) and make unknown functions known (not really working though) in order to compile the lib.
With 2.5.4 things can only get better. I released two patches recently that made it to CVS (socket support and wxDateTime::Format()), that didn't work before, because of the platform not supporting some needed functions. The file API could need some testing, too. I experienced some problems with simple stuff like wxGetTempFileName(). Looking at the code I think that most errors can be fixed by #ifdefing the sources a little more. It just takes some more time until every error has been found.
As ABX said: If you use it, it's best to use a debug version. You'll find some errors and you'll normally be able to fix it. In that case: Patch it and release the patch so things get better
OS: OpenSuSE, Ubuntu, Win XP Pro
wx: svn
Compiler: gcc 4.5.1, VC 2008, eVC 4
"If it was hard to write it should be hard to read..." - the unknown coder
"Try not! Do. Or do not. There is no try." - Yoda
wx: svn
Compiler: gcc 4.5.1, VC 2008, eVC 4
"If it was hard to write it should be hard to read..." - the unknown coder
"Try not! Do. Or do not. There is no try." - Yoda
So you mean wxSocketBase & Co. was not supported yet? Good to hear that it changed. I wrote a Jabber "Library" (http://wxxcd.sf.net) for wxWidgets and I want to write a new Jabber client (that should also be portable to winCE/PocketPC) maybe you know my old client wxSkabber.
I was wondering if the wxSocket stuff is working fine in async mode.
My "lib" supports both, wxSocket and native win32 socket. Is the win32 socket code (using WSAAsyncSelect) not nearly 100% compatible with winCE API?
And another question: how big(kb) will the minimal sample be on winCE?
Thx
I was wondering if the wxSocket stuff is working fine in async mode.
My "lib" supports both, wxSocket and native win32 socket. Is the win32 socket code (using WSAAsyncSelect) not nearly 100% compatible with winCE API?
And another question: how big(kb) will the minimal sample be on winCE?
Thx