Re: [fpc-pascal] fpGUI Toolkit v0.7-rc1 for FPC 2.4
Schindler Karl-Michael het geskryf: has there been already been work on a carbon backend of fpGUI? Felipe started a Carbon backend for the old v0.4 fpgGUI (years ago), but there was hardy any real code, just basic class declarations. Then Apple reported that Carbon will not be 64-bit. Carbon support was then discontinued and work on Cocoa bindings for FPC was started instead. I don't know Mac's at all, so I have no idea how far FPC bindings support to any Mac API (Carbon or Cocoa) is progressed. I do know fpGUI with the X11 backend does run under Mac OS X with the X11 support. Obviously it doesn't look anything like a Mac OS program, but at least the programs run. :) Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpGUI Toolkit on WinCE
Paul, yes I agree with you, that fpGUI is very nice for embedded GUI systems - and I think it has potential for more. The next thing I will look at, is why it draws a frame around labels etc. in WinCE - do you have the same issue ? Should be a minor problem. Adrian. Am 16.03.2010 17:59, schrieb Paul Breneman: Adrian, Thank you *very* much for getting fpGUI working better on WinCE. A few months ago I spent quite a bit of time doing the initial work but as you've seen in the comments I only had a Motorola Symbol MC1000 barcode scanner to work with and that just has a 240x240 monochrome display. I hope to get a better WinCE system like this to use with fpGUI: http://www.cubloc.com/product/06_02.php I've been using fpGUI on this 7 Linux touchscreen: http://www.embeddedarm.com/products/board-detail.php?product=TS-TPC-7390 If fpGUI gets DirectFB support that should help on the low-powered Linux systems. When I did all my work a few months ago I hoped someone else would come along to take it further so I am *very* pleased to see your messages today. It appears it is going to get even easier to show how FreePascal and fpGUI provide simple entry to embedded GUI systems. :) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpGUI Toolkit on WinCE
Am 16.03.2010 16:11, schrieb Graeme Geldenhuys: On 16 March 2010 15:03, Adrian Veith adr...@veith-system.de wrote: Now my second solution works: Thank you very much. I'll take a look at the code and test on my Garmin in the next day or two. yes please, and if it works please fix the code on git. I will also look at the issue with frames around labels etc I have read, that you mentioned to think about AggPas as a target for fpGUI. For me it would be very interesting to combine both (I fixed already the code of AggPas to compile for ARM, but there is a problem, that the demo applications don't start - I guess its a missing system call). I would like to have a small widget set (pure pascal, so that it can be easy ported to all the platforms fpc can target) with very mighty drawing capabilities, which can be styled like HTML and CSS. For example: why do we need widgets like Panel and Button and Bitmap Button (if I look at my Delphi installation, which is still my main developing environment - I have about 50 different Button widgets and about 20 Panels). In fact all are rectangular areas which are drawn with different styles and borders, some are transparent, some contain images, some are for toolbars, some can contain styled text. If I look at HTML you have a div with different styles and depending if you have events attached to it or not, it behaves like a button or a panel. That kind of simplicity and flexibility is what I want - separate code from layout and design, but with mighty design possibilities. That's why I look at fpGUI. fpGUI has very straight forward design and is easy to change and runs on all platforms. If we bring the amazing drawing capabilities of AggPas to fpGUI and have a (to be written) style engine a la CSS - et voila we could have a little gemstone, which is far beyond existing frameworks - ok. I am dreaming now ;-). Adrian. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is it save to think default value of untouched string is ''?
security rule #1 : never assume anything... 2010/3/7 lyh1 lyh1...@hotmail.com: But ShortStrings also store the length in string[0]. If I do a append, I think the string will append to string[1] So don't assume string are always initialized with null string? Message: 5 Date: Sun, 7 Mar 2010 00:17:03 +0100 From: Mattias Gaertner nc-gaert...@netcologne.de Subject: Re: [fpc-pascal] Is it save to think default value of untouched string is ''? To: fpc-pascal@lists.freepascal.org Message-ID: 20100307001703.2a1b2...@limapholos Content-Type: text/plain; charset=US-ASCII SetLength does not initialize the string characters. ShortStrings are not always initialized. Mattias ___ fpc-pascal maillist - fpc-pas...@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Versions x.x.1, x.x.3, x.x.5 are development versions? or are bug fixes?
Versions x.x.1, x.x.3, x.x.5 are development versions? or are bug fixes? Ex.: 2.4.1 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Versions x.x.1, x.x.3, x.x.5 are development versions? or are bug fixes?
On 18 Mar 2010, at 00:10, Osvaldo Filho wrote: Versions x.x.1, x.x.3, x.x.5 are development versions? or are bug fixes? Ex.: 2.4.1 x.[0,2,4,6,9].[1,3,5,7,9] are bug fixes versions (with also minor features that should not affect stability too much) x.[1,3,5,6,9].x are development versions So 2.4.1 is a bug fix version. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Versions x.x.1, x.x.3, x.x.5 are development versions? or are bug fixes?
Please, where is this information? 2010/3/17 Jonas Maebe jonas.ma...@elis.ugent.be: On 18 Mar 2010, at 00:10, Osvaldo Filho wrote: Versions x.x.1, x.x.3, x.x.5 are development versions? or are bug fixes? Ex.: 2.4.1 x.[0,2,4,6,9].[1,3,5,7,9] are bug fixes versions (with also minor features that should not affect stability too much) x.[1,3,5,6,9].x are development versions So 2.4.1 is a bug fix version. Jonas___ fpc-pascal maillist - fpc-pas...@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Versions x.x.1, x.x.3, x.x.5 are development versions? or are bug fixes?
On 18 Mar 2010, at 00:30, Osvaldo Filho wrote: 2010/3/17 Jonas Maebe jonas.ma...@elis.ugent.be: On 18 Mar 2010, at 00:10, Osvaldo Filho wrote: Versions x.x.1, x.x.3, x.x.5 are development versions? or are bug fixes? Ex.: 2.4.1 x.[0,2,4,6,9].[1,3,5,7,9] are bug fixes versions (with also minor features that should not affect stability too much) x.[1,3,5,6,9].x are development versions So 2.4.1 is a bug fix version. Please, where is this information? http://www.freepascal.org/faq.var#versions Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: tstringlist.savetostream
OK,
I had a bunch of WriteLn in my program, so that is how I knew it was running to
completion. But I have removed them for this test. I changed my source from sending a chr(4) to
pipe.closeinput, which seemed to give a little cleaner run in Lazarus. My test linux command is
just a ls -l to keep it simple.I am still not getting any jobs created in the AT
Facility from my test fpc program. But I have some output from strace, but am not sure how to
interpret it:
execve(./teest, [./teest], [/* 42 vars */]) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=10240*1024, rlim_max=RLIM_INFINITY}) = 0
rt_sigaction(SIGFPE, {0x41f520, [], SA_RESTORER|SA_SIGINFO, 0x400d78}, NULL, 8)
= 0
rt_sigaction(SIGSEGV, {0x41f520, [], SA_RESTORER|SA_SIGINFO, 0x400d78}, NULL,
8) = 0
rt_sigaction(SIGBUS, {0x41f520, [], SA_RESTORER|SA_SIGINFO, 0x400d78}, NULL, 8)
= 0
rt_sigaction(SIGILL, {0x41f520, [], SA_RESTORER|SA_SIGINFO, 0x400d78}, NULL, 8)
= 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
readlink(/proc/self/exe, /home/terry/Documents/fpc/CommandProg/teest, 255)
= 43
open(/etc/timezone, O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or
directory)
stat(/etc/localtime, {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0
open(/etc/localtime, O_RDONLY|O_LARGEFILE) = 3
read(3, TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0\0\0\0..., 2048)
= 2048
mmap(NULL, 262144, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f513a9c4000
mmap(NULL, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f513a9bc000
mmap(NULL, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f513a9b4000
mmap(NULL, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f513a9ac000
close(3)= 0
time([1268875052]) = 1268875052
mmap(NULL, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f513a9a4000
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
readlink(/proc/self/fd/1, /dev/pts/4..., 255) = 10
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
readlink(/proc/self/fd/0, /dev/pts/4..., 255) = 10
ioctl(1, TIOCGWINSZ, {ws_row=63, ws_col=209, ws_xpixel=0, ws_ypixel=0}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_START or TCSETS, {B38400 -opost -isig -icanon -echo ...}) = 0
write(0, \33[6n, 4) = 4
select(2, [1], NULL, NULL, {1, 0}) = 1 (in [1], left {0, 997000})
read(1, \33[63;1R, 256) = 7
write(1, \33[m, 3)= 3
pipe([3, 4])= 0
pipe([5, 6])= 0
pipe([7, 8])= 0
access(at, F_OK) = 0
fork() = 7010
close(4)= 0
close(5)= 0
close(8)= 0
write(6, ls -l\n, 6) = 6
read(3, , 1024) = 0
--- SIGCHLD (Child exited) @ 0 (0) ---
read(7, , 1024) = 0
close(6)= 0
ioctl(1, SNDCTL_TMR_START or TCSETS, {B38400 opost isig icanon echo ...}) = 0
munmap(0x7f513a9b4000, 32768) = 0
exit_group(0) = ?
Message: 5
Date: Wed, 17 Mar 2010 06:52:50 +0100 (CET)
From: mar...@stack.nl (Marco van de Voort)
Subject: Re: [fpc-pascal] Re: tstringlist.savetostream
To: FPC-Pascal users discussions fpc-pascal@lists.freepascal.org
Message-ID: 20100317055250.144d617...@turtle.stack.nl
Content-Type: text/plain; charset=US-ASCII
In our previous episode, Terry A. Haimann said:
Virtually the same logic in a fpc program doesn't work. The program
runs, but nothing is submitted to the AT facility. I am suspecting
something is requiring one of the libraries in Lazarus that I can't seem
to get to compile in fpc such as fileutil, LResources or maybe
Controls. But I may be missing something else. Something could be
going on with the pipes that I don't understand. I don't know of a way
to monitor the pipes or the AT Facility to see what is going on. I am
running FC10-64
As said before, the FPC program might simply terminate and take the AT job
with it. Let it pauze at the end, e.g. a readln, and see if that makes a
difference.
A tool to see what is going could be strace
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
