How good is the fltk 2.0 - I want to use it to avoid porting
in the future.
It works well, on a good day. But there are sections that are still
(more or less) alpha, so occasionally it breaks as enhancements are
checked in... (Although this has happened less often recently.)
Also, the API may
Recently i bought a Windows Mobile (6.0) device and started a port
of fltk (1.1.7) to wince using cegcc in cygwin mode.
crosscompiling on windows (cygwin, no Visual Studio) i used also a
handcrafted makeinclude and config.h file.
i did some sourcecode modifications, mostly to work around
Hi, I should ask if someone know how and if is possible on fltk 2
replace a menu item
from a char. In 1.6 version
I can simply do it as follow:
m1-replace(0, charX);
but I cannot find similar method in fltk 2.
I'm not big on fltk2, but here's a guess anyway.
First off, I'm
In case you have been wondering why I have not checked in the UTF-8
patch yet: I have been reading the diffs for the last few
days, and I
was quite surprised about the amount of code that needs to go into
UTF-8 support.
Yup, it can be quite tricky, but if we get the right
You are right Fl_Menubar don't set a type value.
I'm trying to create a dynamic menu, so I need to create just
a Fl_Menubar object in window, but I don't know how confirm
if a windows has a Fl_Menubar on it.
Hmm, maybe you could make a subclass of Fl_Window (say) that includes a
pointer
Is there any interest in this community of keeping alive a
nightly build/testing dashboard for FLTK? Read on for the
motivation behind the question...
What's the thinking on this?
I guess this sort of thing is nice, but I doubt that there's enough
churn in the fltk codebase just now for
when i call fl_window-show() form timercallback, window is
apper on top
but keybord event is another application( i.e. current
working application) how set keybord event to top window
It might help if you tell us what version you are using, and what
platform you are on.
Note that
Thanks MacArthur,
but fl_window() is not hide(); it is backside of current
application
OK - to be clear:
I think what you are asking is how to raise a window to the top of the
stack, that is not currently hidden, and *is not* a window of the
currently focussed application?
If the window
hi there is support animated gif in fltk 1.1.x (l.e.browser)
There is no built-in support for animated gif's, although it is pretty
easy to write your own.
There may be some examples around - maybe on Greg's website?
http://www.seriss.com/people/erco/fltk/
SELEX Sensors and Airborne Systems
Question: How come that the SVN of V2 and the SVN of V1.3 use
a wildly different PNG library?
Fltk-2 doesn't seem to be as actively maintained as the 1.1.x and 1.3.x
series, so a lot of things in it are well behind the curve. So if you
need latest stable, you should probably be using 1.1.9
I think the best thing can be done for attracting users is a
stable version,
We have a stable version, it's called 1.1.9. I've been using the 1.1.x
series for years, and it's been very reliable.
Unfortunately, the same can't be said of 2.x - I've been trying it on
and off for years, and it
That is what I meant. Now that we have stable fltk1, we can
1) Adding new bugs to it through adding new features
1.1.9 is closed. Unless someone finds a show-stopper, it will be that
way forever. We don't expect there ever to be a 1.1.10.
Any new 1.x style work will go into the experimental
I agree. If you manage to motivate enough reliable dvelopers, I will
join the merging process. I will not abandon F1 though for
the reasons
mentioned above.
What Matthias said. Ditto from me. If I saw fltk-2 becoming stable, I'd
certainly jump in, but right here, right now,
As I understand it v2 is more likely to be acceptable for
mainsteam users cross platform.
Not sure I understand this assertion - what makes you think fltk-2 will
be more acceptable to users than fltk-1.1?
They don't look much different from the outside. I wouldn't expect an
end user to know
And now comes the big trick:
- we create the F3 OS support and core by *moving* and
merging F1 and
F2 core files (see the list above). The trick is not to *copy* those
files, but to *move* them. That means that F1 and F2 will *loose*
functionality in its own core, but will regain an
No problem, been there, done that. Is there a better way to
report these kind of findings?
Posting here is fine, I think.
Also raising an STR to make sure we don't forget is even better!
http://www.fltk.org/str.php
SELEX Sensors and Airborne Systems Limited
Registered Office:
to something like this:
typedef unsigned short Fl_Align;
const Fl_Align FL_ALIGN_LEFT = 4;
const Fl_Align FL_ALIGN_INSIDE = 16;
to get back to the readable, but somewhat unsafe:
myWidget-align( FL_ALIGN_LEFT | FL_ALIGN_INSIDE )
I kind of like the look if that.
But I've
BUILD: [01:000108:ERRORE] teststaticlib.lib(Fl.obj) : error
LNK2019: unresolved external symbol ___WSAFDIsSet referenced in function
public: static void __cdecl Fl::add_fd(int,int,void (__cdecl*)(int,void
*),void *) ([EMAIL PROTECTED]@@[EMAIL PROTECTED]@Z)
BUILD:
Hi all.
I successfully compiled fltk.
Then I compiled the editor.cxx example.
The example runs very well and fast but I have one problem.
I am not able to drop a file onto the application bundle.
Is it possible to open files with drag and drop from the finder?
Yes, this is possible.
If
we get this additionally. However, I don't know, if the code with
WSAAsyncSelect() has ever been tested and would be working. Does
anybody know this?
When I was working up my fltk-118 UTF-8 patches, I tested that, and it
did not seem to work, but when I looked at the code (very briefly!) it
If this is so, then we could simply put
#define USE_ASYNC_SELECT
in the winsock2 conditional path, and that's it (?).
That was my expectation when I tested this last (1.1.8 on winXP), and
ties in with what Mike says - but... It didn't actually work for me when
I tried it, so I'm not
With that being said,
FLTK is nice, fast, a bit unstable and experimental - but definitely
usable.
You are using fltk-2 IIRC? If you find it a bit unstable and
experimental for your needs, you should maybe give fltk-1 a spin too -
it is intended as the stabel and NOT-experimental branch, so
Fabien,
According to Ian, it should also work on IRIX platforms and
You probably mean Greg here, I think? I haven't seen an Irix machine in
years!
(Note: technically I have *seen* an Irix machine - there's a bank of
them at the far end of the floor above - what I *meant* was that I have
not
You probably mean Greg here, I think? I haven't seen an
Irix machine in
years!
Yeah, sometimes I turn it on to heat up the room,
or to run soundeditor to record stuff off the radio..
You presumably have to record the radio because you can't hear it over
the noise of the
A while back (July 2008), one of my colleagues here found a bug with the
initialisation of his spinner control in fluid, and posted an STR for
it, along with a suggested patch.
It was filed as STR #1991, but when I was trying to refer to it today I
couldn't see it on the Bugs and Features
I'd be willing to take a stab at making a Makefile.WINDOWS
for fltk for the MS compilers if that would be entertaining.
Brave man!
One thing - can you call it Makefile.MS (or similar) please, as I
already have windows makefiles, for non -MS tools...
Cheers,
--
Ian
SELEX
Another subject that I have been torturing my old brain about.
I came up with an XML (or whatever) database containing unified
instructions for building every library and executable in the
archive.
The XML then gets merged with multiple IDE description files
(extracted from an
Yes, I've often been a proponent of this over the years;
a separate officially supported 'extras' or 'extensions'
lib that does things slightly out of the strict scope of
the fltk core, either slightly complex 'bloaty' widgets,
or things that might be considered
It would be interesting to determine whether we can make the exising
makefiles work with VC++ with a new makeinclude and config.h header.
Oh, now that sounds interesting - and it could maybe work... I suppose
we still need to provide a configure mechanism somehow though, since
it is unlikely
As for TCP/IP, I'm not sure there's any point wrapping
that, is there?
The socket layers all look much the same these days, and my
code pretty
much just compiles...
OK, so at the very least we could hide the mess that is Winsock.
There is also the whole issue of IPv6 support -
Winding myself through the depths of Unicode and utf8
encoding, I have
You are in a maze of twisty passages, all exactly alike...
come across GLib. GLib is part of the GTK toolkit and incorporates
everything that the GUI part of GTK needs to work, but wihich is not
strictly GUI
OK, so I have no problem with using glib with Pango and X11/Cairo,
however glib isn't fast or light or standard outside Linux/Solaris,
so I wouldn't want to make it a dependency on other platforms. In
particular, glib on Windows still has a lot of issues...
Indeed so, and for simply
Thanks for all the suggestions. I will use a combination of 1 and 2
then. I merge the code base with the patch (done), then make all the
IDEs and Makefiles work that I can test (Linux, OSX, Xcode,
VC6, VC7,
VC8) and merge back into the trunk.
Outstanding! That was really quick...
I'd be happy to test your build with my commercial app
in Japanese.
OSX has been the one platform I haven't yet been able to run in
Japanese mode.
What! My dirty hack wasn't good enough for you then? ;-)
Cheers Greg,
--
Ian
SELEX Sensors and Airborne Systems
Understanding more and more about languages, script, glyphs, fonts,
and layouts, I realize that we can never produce a perfect UTF8
support. So let's keep it fast and light and allow rendering of all
fonts and simple text input. The existing code base is just fine for
that.
Yup - I
If you have a modification which effects more than one file
should you submit multiple patch files, ie one for each file
modified, or should it be in one big patch file?
I don't think there's a clear policy on this - either way works, as long
as the patch files are clearly indicated in the
Allrighty, I decided to release the utf8 patch into the Wild
(in this
case, into the Trunk of the SVN).
Way to go! That was very swift...
But this also means that this particular SVN version of FLTK 1.3 is
very buggy! Here are a bunch of issues that I have found so far:
- Makefile
This patch would break OS X and Linux builds. As you see from
the last
commit, I try to touch Makefiles as little as possible,
because every
little change here triggers another problem on some platform
I usually
have never heard of... .
A more correct version of the patch would
Does it crash only on Vista?
It works for me on WinXP, no problems.
Not only Vista; it crashed for me on XP (just synched my svn and
rebuilt) but there was a verbal report from another user here that this
crash had been seen previously, on a recent but pre-UTF-8, 1.3.x
checkout.
OK -
Upside down text on OS X means that it has not found the requested
font. The text matrix call fails with it, and with it the font
flipping (which is needed because FLTK has the coordinate origin in
the top left, wheras Aqua sets the origin in the bottom
left). This is
likely to
Here is a screen capture that illustrates what is possible with it:
http://pbil.univ-lyon1.fr/members/mgouy/data/XcodeWin32Plugin.png
That's quite impressive, actually.
Any interest in that from MacOS X FLTK developpers ?
Possibly - there are a few Xcode users around here that might find
As Bill mentioned elsewhere, it is possible to distinguish
between small
int values and pointers as the pointers have relatively large values
(using low adderesses for OS etc)
How robust a hack assumption is that? I'm wondering about systems
(increasingly common these days) that do
+1 for resizing
+1 for (raw) image (data) handling
Some howtos already exist for these topics... How easy is it to absorb
them into the doxygen? (I have no knowledge of how doxygen works with
this...)
SELEX Sensors and Airborne Systems Limited
Registered Office: Sigma House, Christopher
Removing the X11/Intrinsinc.h worked well on both Fedora 4
and recent Ubuntu 8.04
This said, there are two things to report:
1. Removing this including should also be followed by a
string.h include in replacement as otherwise, we don't get
the memcpy prototype declaration at least on
Anyway - returning to the question at hand... Do we
actually need Xext
or not?
I'm not even clear as to what it provides!
I'm not a unix X11 geek too, so I used the nm tool on libXext
to look at the APIs listing, then used grep to look if we
used some extensions prefix and it seems
OK, this is interesting... Does it fail to render the
ISO-8859-1 characters on all platforms, or is it only on linux?
There's something I saw in the linux parts of my utf8 code
that might be implicated here... But if it isn't working on
OSX or win32 either it may be a more general
as per your suggestion, there is no file like libXext.and
libXext.so in cross compile environment, but it is there
in host environment in /usr/lib.
my question is how to obtain libXext.so???
If it is not there, it is probable that the X-server for your target
platform does not provide those
have added --disable-xdbe in configure option and ran the script
Good.
# libraries to link with:
AUDIOLIBS =
DSOFLAGS= -L. -L/home/vinayak/arm-2007q1/lib
LDFLAGS = $(OPTIM) -L/home/vinayak/arm-2007q1/lib
These lines look
As per your direction have removed the lXext
this time i got cannot find -lX11.
OK. Do you have the X-windows client libraries for your cross-target,
and their associated dev packages, installed?
Even if i removed the both lXet as well as
-lX11 from makeinclude, different errors are
before that i need to say one thing.
earlier while compiling got a an error which some thing like this:-
Fl_x.cxx:239: error: impossible constraint in 'asm'
Fl_x.cxx:240: error: impossible constraint in 'asm'
Fl_x.cxx:241: error: impossible constraint in 'asm'
If those
Here's my 2 cents for helping to isolate from where it may come:
0. go to system prefs/users and check in the Startup/Open
thumbnail that you don't have any booting software starting
when you open a session.
None.
If you have any external usb or firewire controller device
unplug it for
I suspect this doesn't work all that well, particularly on
linux/XFT,
where I suspect that this workaround is partly inhibited by
my decision
to render the text strings using XftDrawStringUtf8() directly.
Ah, meanwhile I checked that I use xft on linux. I'll try
again without,
Last night I was trying out Fabien's Cairo patch on my laptop under
Vista (with Msys/mingw) and had a problem with the generated makeinclude
file.
I assumed this was finger trouble on my part and tweaked the makeinclude
to work, but it happened again on this XP box, so I actually had a look.
Fabien (et al)
Is it intended that the --enable-cairo option means the generated code
always depends on Cairo?
I had expected it would work like OpenGL does - if you use it, you need
to link it in, but if you aren't using it, you don't.
But, what I find is that if I build fltk-1.3 with
Or something as Fl_Window::set_class(myClassName) would be
IMHO even better in that case.
Yes.
I wonder though - if the app has several windows, would we expect to set
the window-class individually per window, or would it be a static such
that setting it once sets it for all windows?
(I'm
Talking about that one and utf8 impl. for OS X,
I was starting to correct some Quartz FIXME ... when I
noticed that the QD impl. is _broken_ on OS X.
I guess it has to do with the new fl_font_mac.cxx API's and
behavior like this fl_rtl_draw() API.
Yes, probably my fault - I gave up on QD
imacarthur wrote:
Hmm, I don't think I expect any warnings... We probably
want to start
gathering up the reports of warnings and fixing them, actually...
Here they are, all of 'em #warning ...
Compiling Fl_x.cxx...
Fl_x.cxx:341:2: warning: #warning XFT support here
On Wed, 2008-10-01 at 11:38 -0700, Nikita Egorov wrote:
Dont forget that DirectFB is (at the moment, of course)
lowlevel library!
For example :
It has no methods to draw/fill arc and polygons.
I thought I might use Cairo to do those things.
I'd hazard that that would be a lot more work
The only feature of a window manager I wanted is the frame and window
decorations and possibly the ability to move some pop-up dialog boxes
with the pointer. I've used Qt Embedded to do a GUI on Linux
framebuffer (not DirectFB) and it offers the option of running your
application as the
Here's a link to the new pdf manual I generated,
as explained with doxygen 1.5.7 on Mac OSX 10.5.5, with tetex tools
installed from macport tools :
http://fab672000.free.fr/fltk/fltk13-refman.zip
I believe we don't need all the details (and there is not all
the images yet) but it's lot
Can we simply have two targets? Like:
make pdf
and
make pdf-dist
The second target only would execute the copy command.
Sounds sensible: +1
SELEX Sensors and Airborne Systems Limited
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14
3EL
A
For reasons to tedious to recount here, I was looking at the way we name
shared libraries...
Anyway, I noticed a couple of things that might need to be looked at;
AIX:
The AIX shared libs don't have a FL_API_VERSION anywhere in their
name, so there's a real chance that someone might try to
Thanks for your support n guidence. I have successfully
cross compiled fltk as well as Xwindows for arm target board.
Congratulations - I am very pleased that it is working for you.
Once again Million Thanks
You are most welcome.
One thought - if you had the time, it would be
- If it's to use XCB on winXX, then, erm, why? It already works
nativley on winXX, so it is not clear what a port to use an
intermediate abstraction layer would add...?
imacarthur.. been thinking if this could possibly be an interesting
way to remote win apps to thin clientsadmittedly
All,
What follows is kind of in 3 parts, but all jumbled in together: partly
me proposing an enhancement to fltk's text handling API, partly me
asking for suggestions for my current problem, and partly me making some
observations on the current method.
Probably this needs broken out as a couple
OK. Based on Bill's points, rather than messing with the
existing API
at all, I'll just try and add an fl_text_extent mechanism (name
TBD) just as a proof of concept for now. Then if that seems to be
working for us, we can build on that, perhaps.
Hm, well, I had a little time last
So - anyone got any useful tips for measuring actual text extents on
win32? (Short of just calling Cairo!)
Answering my own question (see, it's got so bad now, I'm talking to
myself via email, not just verbally) the solution seems to be to do
something compicated... Convert the text string
I have a query regarding FLTK and Korean string.
I have a board which uses ARM OS. I build my firmware on Linux OS. I
have application part and underlying FLTK engine.
Which fltk version? 1.1 doesn't really handle UTF text, 1.3 and 2.x more
or less do.
Also, which font backend is your
This used to work correctly, AFAICT, under mingw (and I think cygwin
too) so I suspect we have broken something. However, as you note, it
*seems* to be fine on Linux and OSX, so my be some
interaction with the
configure tools on win32?
No I don't think it worked correctly before too
Maybe a temporary fix in the 1.3 branch like adding another
if clause, as I found
out to be working? This would be better than now, at least.
Yes, I guess that might be best for now - that sort of takes us back to
the previous behaviour where it checked in two stages... Turns out that
Albrecht Schlosser wrote:
Thanks, svn -r6505 fixes the --enable-localpng (cygwin
build) problem.
I didn't test anything else, though.
After testing some more cases:
Now it works with explicitly using --enable-localpng or
--disable-localpng, but not with the default (none of
solution, IMHO - to write safe typedefs (allthough i would prefer
int8_t, int16_t, int32_t and int64_t as oppsed to INT*)
I like the stdint types, but is it safe to assume every platform we
support has them? If so, then I'd suggest we move towards adopting
them...
SELEX Sensors and
Same here on WinXP. I used the font Adobe Ming Std L,
because I don't have Arial Unicode MS.
The Arial Unicode MS is quite handy, if you can find a copy (there are
a few things kicking around the web with that name, but they seem not
all to be the real thing. The real version is about 22.5
I looked around a bit, and I found something that told me
that it would
be automatically installed with WinXP, but I think that it
comes with
MS Office. Further search showed that MS sells it for $99.
I don't need no MS Office, and I won't buy a MS font for $99 ;-P
Yes - I think MS
Anyway, setting/getting functions (mostly inline) using
overloading is
fine and elegant, my small complain is with overloading the virtual
functions. This caused this pesky shadowing - ie for draw()
of Fl_Image
classes, and redefinition of all overloads to make it public or down
Does this fix it?
Yup, that seems to have got it.
SELEX Sensors and Airborne Systems Limited
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14
3EL
A company registered in England Wales. Company no. 02426132
All,
How do people feel about my fl_text_extents patch (STR #2076)?
I don't know how to get something new like that added to the API.
This change is very useful, to me, so I'd very much like to push it into
the source, but how do I get agreement for that?
Is the proposed API acceptable? Does it
I remembered an early discussion where someone made
a point whether it should take a single character
or a string.
OK - I went for a string. I reckon an individual character is just a
short string anyway!
SELEX Sensors and Airborne Systems Limited
Registered Office: Sigma House,
Not official answers, just my opinion...
as you can see at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=364295 I'm
working on a Debian package for fltk2 (needed by dillo
etc...), however I've few questions for you:
- are ABI/API stable?
Probably not, there are still things that
Some questions about fltk-1.3.x-svn
1) Which Microsoft compiler(s) are currently supported
to build fltk-1.3.x
(while its in dev), and what is the correct master
project file to load?
I've noticed visualc/fltk.dsw no longer exists
(which is what README
Albrecht, I have coded up the dynamic loading of GetGlyphIndicesW
and it seems to work as before, on machines that *do* have
GetGlyphIndicesW...
Can you possibly test against a machine that does not, and see what
happens?
All,
Following Albrecht testing my patch with winNT
I'll apply the following patch shortly (compiled okay on my
cygwin box with gcc
3.4.4).
Index: src/fl_font_win32.cxx
===
--- src/fl_font_win32.cxx (revision 6534)
+++ src/fl_font_win32.cxx (working copy)
@@
FWIW, I had a quick look and it compiled ok on vc2005, too.
Fabien
Thanks Fabien,
I do think it is odd though - it seems that some iterations of gcc/mingw
permit this style, others do not, and now you report that vc2005 is OK
with it...
Still, I guess we need to code safely though!
Cheers,
I'm sort of wondering which compiler variants do/don't
allow that style
of usage...
Me too. Which compiler did _not_ like it?
This one complained:
$ gcc -v
Reading specs from d:/MinGW/bin/../lib/gcc/mingw32/3.4.2/specs
SELEX Sensors and Airborne Systems Limited
Registered Office:
Interesting.. if I gather the gist of the patch correctly,
it looks like the change is to avoid having the void function
return() a function that returns a void.
Which seems to compile OK with 'g++ -Wall' on my linux
systems, eg. no compile errors for this:
[ OT: However, I found some strange effects that are the same
in the old
and the new version. There are two images (basn4a08.png and
basn4a16.png) that are obviously displayed wrong under Window
only. I'll
append a pdf file with my test results. But this is a
different story,
Hi All! I need to embed fltk widget into wxWidgets top
window, is exist any manual for this?
I don't recall anybody ever doing that before, so I don't think there is
any documentation for that.
It does not sound easy.
Would you not be better just making your embedded widget with wxWidgets,
Thanks for replay, I have write something like form editor,
but I have problems that cannot solve - Z-order of widgets(
wxWidgets doesn't have such ability ), and also wxWidgets
some slow, but fltk is great for this( I cannot fast rewrite
all application on fltk - it big and written
Timothy,
Is there a list of what functionalities this particular patch adds?
Also, the other patches you have posted - do they need to be applied in
a particular order?
These patches seem to be mainly linux oriented - have you had a chance
to test on other platforms? Are there any known
Indeed - I can write the words, and generate a screenshot,
but have no
idea how to get them into the docs...
Writing the doxygen docs is not that difficult. There are enough
examples, and there are some hints in the developer section
of the docs.
In this special case however I'm
If it's going to be public, I'd suggest avoiding Smart Pointer,
because that phrase historically suggests something a bit different,
namely
smart_pointer p = new Thing; // this will be deleted automatically
Yup, fair point...
SELEX Sensors and Airborne Systems Limited
Registered
(1) your indents are not completely according to the coding standard:
usually the doxygen comments are also indented, and the new
Oh - OK, I didn't know that.
fl_gc code
looks as if it has indents of 4.
Ah, sorry, that'll be wrong tab settings on my editor I suspect...
(2) When we
$ git clone
git://git.directfb.org/git/directfb/ports/FLTK_1.x-DirectFB
I keep getting the following error when I try the above.
fatal: The remote end hung up unexpectedly
Is there another way to retrieve the source?
You'll need to ask that over on the directfb lists - they
I noticed these two new defines in Fl_Browser_.H for 1.3.0:
#define FL_SORT_ASC0 /** sort browser
items in ascending alphabetic order. */
#define FL_SORT_DESC 1 /** sort in
descending order */
Before these become 'written in stone' when
This is exactly why mike suggested to implement release() in
the Fl_Image class I think.
This way, we could avoid completely the need of deleting images.
a release base impl. would just delete himself in the non
shared image impl.,
the shared image would do what it does now.
Implementing
Well ... right.. probably it's not as important as
Fl_Shared_Image API changes but hey ;) maybe someone could do
some testing at least? ;D
I am very interested in your project, and have been following your
posts, but I don't have a compatible device to test on, and right now I
don't have
All,
I've mainly been using fltk-1.3 recently, but today I had to run a build
with fltk-1.1 svn, and the build failed.
The same code/Makefile build OK with fltk-1.3.
A brief investigation suggests that the --compile option is returning
the wrong options for linking the image libs. I think this
but, am I right in thinking that the code above would say that
the string z is less than aa because it is shorter?
If so, something doesn't make sense, or am I missing something?
It does seem this would return -1 in this case, so that z is less
than aa.
Whether that is right or not I do
Markus Kuhn's web page http://www.cl.cam.ac.uk/~mgk25/unicode.html
is actually one of the least dry ones out there about unicode/utf8
that I've come across so far. Apart from a link to the O'ksi'D
FLTK, he also has one to a document containing test characters.
We could investigate
All the functions use Uchar* for their strings, which are all
typedef u_int16_t Uchar;, and not chars.
Oh, yuck. Lets not do that then. Either 32-bit or 8-bit chars are
probably better for us, I think.
SELEX Sensors and Airborne Systems Limited
Registered Office: Sigma House,
1 - 100 of 668 matches
Mail list logo