Re: [fpc-pascal]TThread
On Wed, 23 Jul 2003, Lukas Gebauer wrote: > because I am new in FPC community, can someone explain me what is bad > on threads implementation on FPC? (TThread object interesting me.) 1. Threads don't work in FPC 1.0.X 2. In FPC 1.1, threads are implemented as a language construct (i.e. threadvar etc) and a set of system independent thread handling routines have been implemented. The tthread class must be rewritten to use these routines. Michael. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]XChat plugins using FPC
On Wed, Jul 23, 2003 at 08:50:35AM +0200, Michael Van Canneyt wrote: > > > On Wed, 23 Jul 2003, James Mills wrote: > > > On Wed, Jul 23, 2003 at 03:28:55AM +0200, Marco van de Voort wrote: > > > > I can successully compile and test the plugin source listed at > > > > http://xchat.org/docs/plugin20.html written in C. > > > > > > > > However I don't like C much and am wondering if it's possible to do the > > > > same thing in pascal... ? I know it has to be possible, but I need > > > > someone to start me off in the right direction... > > > > > > Probably yes, but you'll need to convert headers of xchat-plugin.h. The > > > "h2pas" util can be handy for this. (or at least it can save a lot of time) > > > > Okay I've converted the headers (step 1) :P > > > > $ h2pas -S -D -p -l xchat xchat-plugin.h > > at line 6 error : syntax error > > Illegal character in line 6 > > "#define XCHAT_IFACE_VERSION((XCHAT_IFACE_MAJOR * 1) + \" > > at line 7 error : syntax error > > Illegal character in line 7 > > "(XCHAT_IFACE_MINOR * 100) + \" > > > > > > > > What do I do with these errors though ? > > run the file through the gcc preprocessor: > > gcc -E xchat-plugin.h -o xchat-plugin.hp > h2pas -S -D -p -l xchat xchat-plugin.hp > > Note that this destroys all '#define' constants, so you'll have to > run h2pas a second time to get all constants. Okay, I'll try that :) I tried fixing the header file, but obviously you know what to do better than i :P cheers James > > Michael. > > > ___ > fpc-pascal maillist - [EMAIL PROTECTED] > http://lists.freepascal.org/mailman/listinfo/fpc-pascal -- - - James Mills Zero Defect Software Engineers Group - ZDSEG ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]XChat plugins using FPC
On Wed, Jul 23, 2003 at 08:51:10AM +0200, Michael Van Canneyt wrote: > > > On Wed, 23 Jul 2003, James Mills wrote: > > > On Wed, Jul 23, 2003 at 03:28:55AM +0200, Marco van de Voort wrote: > > > > I can successully compile and test the plugin source listed at > > > > http://xchat.org/docs/plugin20.html written in C. > > > > > > > > However I don't like C much and am wondering if it's possible to do the > > > > same thing in pascal... ? I know it has to be possible, but I need > > > > someone to start me off in the right direction... > > > > > > Probably yes, but you'll need to convert headers of xchat-plugin.h. The > > > "h2pas" util can be handy for this. (or at least it can save a lot of time) > > > > Now once these headers are converted... > > > > When writing the plugin source itself, do I need to use PChar's instead > > of pascal strings ? > > Your entry and exit points need that, yes. But all in between can be > done using strings. Kewl thanks :) James > > Michael. > > > ___ > fpc-pascal maillist - [EMAIL PROTECTED] > http://lists.freepascal.org/mailman/listinfo/fpc-pascal -- - - James Mills Zero Defect Software Engineers Group - ZDSEG ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Synapse for FPC
> And the other way around. The main problem with Borland is that it only > supports one and a half platform on one processor. Sure, but Borland is home for Synapse. I create Synapse primary for my programs. I am professional programmer and I create lot of commercial programs by my Synapse. This is reason why Borland is very important for me. Programming is not only compiler, but IDE too! I not see comparable IDE for FPC with Borlands IDE. ;-( FPC is only new playground for me now. Until FPC have comparable GUI based IDE with Borland's IDE, then I cannot use FPC for hard developing. ;-( FPC is new world for me. I do only first step to this world! yes, Synapse is not support lot of other platforms, but why? Because I am on begin of the way. > Don't take it personally. It is meant as constructive criticism for the long > run. However if you are aware of the issues it is easier to work in the > direction Ok. For discussing about internals in Synapse you can use special email list called Synalist. :-) > > this is step back in features of Synapse. In old times it is used by this > > way. However now Synapse can use ANY socket library by dynamic loading. > How? How do I load FPC sockets unit, and avoid compiling in the non working > Linux kernel structuers in e.g. BSD? I not mean pascal library, i mean system library. Under Win32 you can load any DLL with same interface as winsock. Under Linux you can load any '.so' file with same socket interface as libc. This is very important for me, because I need this in my some special commercial programs. Of course, whn I go to platform without dynamic loading libraries, then I still can map my synsock to any static socket library. It is not a problem. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Synapse for FPC
> It's pretty hard to use blocking sockets without multiple threads without > your application halting whenever there is a request that takes a long time > to respond. yes, but... with other large TCP/IP libraries you MUST use threads... with synapse you CAN use threads. This is mojor difference! One day will be finished thread support in FPC and all will be happy. ;-) ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal]Synapse for FPC
LG> yes, but... with other large TCP/IP libraries you MUST use threads... LG> with synapse you CAN use threads. This is mojor difference! One day LG> will be finished thread support in FPC and all will be happy. ;-) Why must I use threads? Following works perfectly for me for many years: ioctl(Sock,FIONBIO,@tmp); // nonblocking All but one applications are single thread. I'm using standard Socket/Bind/Listen/Accept/Connect socekt functions. vtech ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Synapse for FPC
On Wed, 23 Jul 2003, Lukas Gebauer wrote: > > And the other way around. The main problem with Borland is that it only > > supports one and a half platform on one processor. > > Sure, but Borland is home for Synapse. > > I create Synapse primary for my programs. I am professional > programmer and I create lot of commercial programs by my Synapse. > This is reason why Borland is very important for me. Programming is > not only compiler, but IDE too! I not see comparable IDE for FPC with > Borlands IDE. ;-( > See http://www.lazarus.freepascal.org/ The IDE is VERY good. The editor is smarter than Borlands. The form designer is getting closer every day, but it is very usable. > FPC is only new playground for me now. Until FPC have comparable GUI > based IDE with Borland's IDE, then I cannot use FPC for hard > developing. ;-( See above. Michael. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Re[2]: [fpc-pascal]Synapse for FPC
> LG> yes, but... with other large TCP/IP libraries you MUST use threads... > LG> with synapse you CAN use threads. This is mojor difference! One day > LG> will be finished thread support in FPC and all will be happy. ;-) > > Why must I use threads? Because not exists non-blocking large TCP/IP library with lot of protocol implementations! Show me any comparable library with my Synapse or Indy, what is based on non-blocking sockets? I not know it! Primary, you MUST NOT use Synapse! You CAN use Synapse, if you wish. You can use your own non-blocking code. Or you can use non-blocking mode in Synapse too. (some of my customers using this!) -- Lukas Gebauer. E-mail: [EMAIL PROTECTED] http://www.ararat.cz/synapse/ - Ararat Synapse - TCP/IP Lib. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Synapse for FPC
> > I create Synapse primary for my programs. I am professional > > programmer and I create lot of commercial programs by my Synapse. > > This is reason why Borland is very important for me. Programming is > > not only compiler, but IDE too! I not see comparable IDE for FPC with > > Borlands IDE. ;-( > See > http://www.lazarus.freepascal.org/ > The IDE is VERY good. The editor is smarter than Borlands. > The form designer is getting closer every day, but it is very usable. Well, where I get working version for Win32? On screenshot it looking very good, but I not see working lazarus on Win32. ;-( I try to compile them from latest sources. Result? Lot of non-working functions, rest is very very slow... I try it and I not see it as usable. ;-( When I see to latest voting on lazarus page, then I think, lot of people need lazarus for Win32... But lazarus Win32 binary downloads is empty. ;-( -- Lukas Gebauer. E-mail: [EMAIL PROTECTED] http://www.ararat.cz/synapse/ - Ararat Synapse - TCP/IP Lib. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Synapse for FPC
On Wed, 23 Jul 2003 11:36:58 +0200 (W. Europe Daylight Time) Michael Van Canneyt <[EMAIL PROTECTED]> wrote: > > > On Wed, 23 Jul 2003, Lukas Gebauer wrote: > > > > And the other way around. The main problem with Borland is that it > > > only supports one and a half platform on one processor. > > > > Sure, but Borland is home for Synapse. > > > > I create Synapse primary for my programs. I am professional > > programmer and I create lot of commercial programs by my Synapse. > > This is reason why Borland is very important for me. Programming is > > not only compiler, but IDE too! I not see comparable IDE for FPC with > > Borlands IDE. ;-( > > > > See > > http://www.lazarus.freepascal.org/ > > The IDE is VERY good. The editor is smarter than Borlands. > The form designer is getting closer every day, but it is very usable. :) The IDE does only work under Linux, Free-, Net-, OpenBSD. Win32 support is progressing and any helping hand is welcome. > > FPC is only new playground for me now. Until FPC have comparable GUI > > based IDE with Borland's IDE, then I cannot use FPC for hard > > developing. ;-( > > See above. > > Michael. Mattias ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Synapse for FPC
On Wed, 23 Jul 2003, Lukas Gebauer wrote: > > > I create Synapse primary for my programs. I am professional > > > programmer and I create lot of commercial programs by my Synapse. > > > This is reason why Borland is very important for me. Programming is > > > not only compiler, but IDE too! I not see comparable IDE for FPC with > > > Borlands IDE. ;-( > > > See > > http://www.lazarus.freepascal.org/ > > The IDE is VERY good. The editor is smarter than Borlands. > > The form designer is getting closer every day, but it is very usable. > > Well, where I get working version for Win32? On screenshot it looking > very good, but I not see working lazarus on Win32. ;-( I was of course referring to the Linux version :-) > > I try to compile them from latest sources. Result? Lot of non-working > functions, rest is very very slow... I try it and I not see it as > usable. ;-( > > When I see to latest voting on lazarus page, then I think, lot of > people need lazarus for Win32... But lazarus Win32 binary downloads > is empty. ;-( This is correct. The lazarus team needs people to help develop the win32 version. The Linux version, on the other hand, is VERY usable. Michael. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Ummmm... anyone know why this doesn't work...
The answer is simple, but very illusive!!!
while (GetMessage(wmsg, FWindowHandle, 0, 0)) do begin
if not ( IsDialogMessage(FWindowHandle, wmsg) ) then ///this is the
line you nees to add
TranslateMessage(wmsg);
DispatchMessage(wmsg);
end;
If you look at what TranslateMessage actually does it all becomes clear.
Matt
- Original Message -
From: "L D Blake" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, July 23, 2003 3:17 AM
Subject: [fpc-pascal]U... anyone know why this doesn't work...
> Ok, 3 checkboxes defined on a small window on win2000...
>
>
> s := 'Start processing when loaded';
> OToy[1] := createwindow('Button',Cstr(S,cpt),ws_tabstop or
> ws_child or ws_visible or bs_autocheckbox,
> 10,15,185,20,Ohandle,1,mdrProg,nil);
> s := 'Exit when done';
> OToy[2] := createwindow('Button',Cstr(S,cpt),ws_tabstop or
> ws_child or ws_visible or bs_autocheckbox,
> 10,35,180,20,Ohandle,2,mdrProg,nil);
> s := 'Make noise when done';
> OToy[3] := createwindow('Button',Cstr(S,cpt),ws_tabstop or
> ws_child or ws_visible or bs_autocheckbox,
> 10,55,180,20,Ohandle,3,mdrProg,nil);
>
>
> Cstr is a pascal to c string converter routine that takes a normal pascal
> string (S in this case) and hands the winAPI a pointer to a null
terminated
> buffer (cpt)... tested and working elsewhere as well so that's not the
> problem.
>
> The little app is up and going, error free, but for the life or me I can't
get
> the ws_tabstop function to work... When the app loads nobody has focus and
I
> can hit the tab key all day and nothing happens...
>
> Why can't I tab between these controls?
>
> -
> L D Blake
>
>
> ___
> fpc-pascal maillist - [EMAIL PROTECTED]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Ummmm... anyone know why this doesn't work...
Tabbing through controls is handled in DefDialogProc() when 1) dialog is
modal or 2) you call IsDialogMessage() explicitly. I have no idea how to
implement this when the buttons are inserted into a window of another
class (when DefDialogProc is not the window procedure); certainly it is
possible somehow. An option is to trap keypress messages and do the
tabbing yourself.
hope this helps,
Ingmar
On Tue, 22 Jul 2003, L D Blake wrote:
}Ok, 3 checkboxes defined on a small window on win2000...
}
}
}s := 'Start processing when loaded';
}OToy[1] := createwindow('Button',Cstr(S,cpt),ws_tabstop or
} ws_child or ws_visible or bs_autocheckbox,
} 10,15,185,20,Ohandle,1,mdrProg,nil);
}s := 'Exit when done';
}OToy[2] := createwindow('Button',Cstr(S,cpt),ws_tabstop or
} ws_child or ws_visible or bs_autocheckbox,
} 10,35,180,20,Ohandle,2,mdrProg,nil);
}s := 'Make noise when done';
}OToy[3] := createwindow('Button',Cstr(S,cpt),ws_tabstop or
} ws_child or ws_visible or bs_autocheckbox,
} 10,55,180,20,Ohandle,3,mdrProg,nil);
}
}
}Cstr is a pascal to c string converter routine that takes a normal pascal
}string (S in this case) and hands the winAPI a pointer to a null terminated
}buffer (cpt)... tested and working elsewhere as well so that's not the
}problem.
}
}The little app is up and going, error free, but for the life or me I can't get
}the ws_tabstop function to work... When the app loads nobody has focus and I
}can hit the tab key all day and nothing happens...
}
}Why can't I tab between these controls?
}
}-
} L D Blake
}
}
}___
}fpc-pascal maillist - [EMAIL PROTECTED]
}http://lists.freepascal.org/mailman/listinfo/fpc-pascal
}
--
Ingmar
--
"I occasionally make the mistake of having social contact with other human
beings."
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Re[2]: [fpc-pascal]Synapse for FPC
> Why must I use threads? You must use threads in blocking tcp/ip else you will hang your application everytime the network traffic slows or the application you connect to (server?) does not immediately respond. Try changing your calls to blocking and see what happens. > Following works perfectly for me for many years: > > ioctl(Sock,FIONBIO,@tmp); // nonblocking > > All but one applications are single thread. Yes. You are using the 'work around'. Traditional UNIX sockets block. Microsoft (and others) realised this would not work with a co-operative multitasking operating system (e.g. Windows 3.1, MacOS 9 and prior) and so the idea of non-blocking sockets was concieved. Indeed M$'s first Winsock implementations used purely Non-blocking sockets. The tcp/ip developer has two avenues to wander down. Use threads and blocking api. It's fast and responsive and we only have to worry about sharing data between threads, or use non-blocking code and then have to work around the fact that tcp/ip can be slow and we will not get all my data in one big chunk. Using Non blocking sockets means that your code becomes more complex and convoluted because you may well have to go through the event look many hundreds of times before your download or upload has completed. Using multiple threads, you simple hand the data over to the thread when uploading and either carry on. Downloading you simply send a message to the main thread when the data is ready. It's also easy to simulate non-blocking sockets with blocking code using threads. This gives you a clear seperation between your tcp/ip mechanism and your application code. This is the route we usually take here. Swings and roundabouts, I know ;-) Matt ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Synapse for FPC
> > When I see to latest voting on lazarus page, then I think, lot of > > people need lazarus for Win32... But lazarus Win32 binary downloads > > is empty. ;-( > > This is correct. > The lazarus team needs people to help develop the win32 version. What is major problem in developing of WIN32 lazarus? For example, I cannot help directly, because I must do my own opensource projects. (it is not only Synapse :-).) I not have time for study lazarus sources. But when some of lazarus developer isolate some WIN32 related problem like "how to do this on WIN32?", then lot of people (include me) can help with answer. Maybe this is done in lazarus e-mail list, I don't know. ;-) > The Linux version, on the other hand, is VERY usable. Great... but Win32 is very needed. ;-) -- Lukas Gebauer. E-mail: [EMAIL PROTECTED] http://www.ararat.cz/synapse/ - Ararat Synapse - TCP/IP Lib. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[4]: [fpc-pascal]Synapse for FPC
ME> Use threads and blocking api. I have (almost) nothing against threads, but they definitely have disadvantages to, especially when used in a huge project: 1. synchronization - need to use critical sections / locks 2. they are very hard to debug and time dependant bugs can be introduced. 3. many libraries (general/graphic/sound/db/etc.) are NOT thread safe That's why I prefer non-blocking single thread solutions. vtech ME> It's fast and responsive and we only have to worry about ME> sharing data between threads, or use non-blocking code and then have to work ME> around the fact that tcp/ip can be slow and we will not get all my data in ME> one big chunk. Using Non blocking sockets means that your code becomes more ME> complex and convoluted because you may well have to go through the event ME> look many hundreds of times before your download or upload has completed. ME> Using multiple threads, you simple hand the data over to the thread when ME> uploading and either carry on. Downloading you simply send a message to the ME> main thread when the data is ready. It's also easy to simulate non-blocking ME> sockets with blocking code using threads. This gives you a clear seperation ME> between your tcp/ip mechanism and your application code. This is the route ME> we usually take here. ME> Swings and roundabouts, I know ;-) ME> Matt ME> ___ ME> fpc-pascal maillist - [EMAIL PROTECTED] ME> http://lists.freepascal.org/mailman/listinfo/fpc-pascal -- Best regards, vtech-fpcmailto:[EMAIL PROTECTED] ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Synapse for FPC
> > And the other way around. The main problem with Borland is that it only > > supports one and a half platform on one processor. > > Sure, but Borland is home for Synapse. Also for FPC. See FPC as yet another Delphi version to support. If you do a large Delphi product that will compile with a lot of versions, you have to make adaptations also. Porting always requires > FPC is only new playground for me now. Until FPC have comparable GUI > based IDE with Borland's IDE, then I cannot use FPC for hard > developing. ;-( Lazarus is coming along nicely. But serverside use is also an option. > FPC is new world for me. I do only first step to this world! yes, > Synapse is not support lot of other platforms, but why? Because I am > on begin of the way. One of the strengths of FPC is that it can go where Borland tools can't. Solaris, *BSD, BeOS, QNX and in the future also non-x86. Not tailoring for that makes FPC use a bit pointless. But changing a few things now and thinking about the way the code is sorted over the diverse files might make future addition of platforms or Delphi versions much simpler. I'm thinking about - dividing stuff over files (units, includefiles), so that alternate versions can be added for other os/processor/version/ > > > this is step back in features of Synapse. In old times it is used by this > > > way. However now Synapse can use ANY socket library by dynamic loading. > > How? How do I load FPC sockets unit, and avoid compiling in the non working > > Linux kernel structuers in e.g. BSD? > > I not mean pascal library, i mean system library. Under Win32 you can > load any DLL with same interface as winsock. Under Linux you can load > any '.so' file with same socket interface as libc. This is very > important for me, because I need this in my some special commercial > programs. Aha, I'm slowly understanding what you are hinting at, and why there is the confusion. Note that I am talking about all those defined types and constants in the source, _NOT_ that you should use the actual functions in unit sockets. You might also want to use some Unix typing in your prototypes (the procedure variables), instead of just putting "integer" etc everywhere. The types in unit socket and Unix describe nearly entirely that "same socket interface" too, (it actually described the libc<-> kernel interface I think, but the differences aer small) but on each platform has its own implementation (under Linux/x86, the linux/x86 version, under PPC the linux/ppc version, under FreeBSD the FreeBSD version etc) > Of course, whn I go to platform without dynamic loading libraries, > then I still can map my synsock to any static socket library. It is > not a problem. So this is not about the dyn-loading, but about defining the interface that you link to. Static or shared. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Re[2]: [fpc-pascal]Synapse for FPC
> > Following works perfectly for me for many years: > > > > ioctl(Sock,FIONBIO,@tmp); // nonblocking > > > > All but one applications are single thread. > > Yes. You are using the 'work around'. Traditional UNIX sockets block. > Microsoft (and others) realised this would not work with a co-operative > multitasking operating system (e.g. Windows 3.1, MacOS 9 and prior) and so > the idea of non-blocking sockets was concieved. Indeed M$'s first Winsock > implementations used purely Non-blocking sockets. Hmm, I think this is more due to the move to event driven programming models than cooperative multitasking. > The tcp/ip developer has two avenues to wander down. The _GUI_ (Event driven) tcp/ip developper. Server processes can use select and fork mechanisms easily too, since network is its main event loop. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Synapse for FPC
> > > When I see to latest voting on lazarus page, then I think, lot of > > > people need lazarus for Win32... But lazarus Win32 binary downloads > > > is empty. ;-( > > > > This is correct. > > The lazarus team needs people to help develop the win32 version. > > What is major problem in developing of WIN32 lazarus? People. Win32 developpers are numerous, but that includes RAD users, while we need RAD implementors. So the good ones that are willing to work on open implementations (freeware/open source/pd) strangely are more rare on win32 than Linux. > For example, I cannot help directly, because I must do my own > opensource projects. (it is not only Synapse :-).) I not have time > for study lazarus sources. But when some of lazarus developer isolate > some WIN32 related problem like "how to do this on WIN32?", then lot > of people (include me) can help with answer. This might become more important in the future. The main problem is a central figure that does a lot of the work. Recently Micha Nelissen started working seriously on win32/Lazarus, and it improved a lot in a few weeks. > > The Linux version, on the other hand, is VERY usable. > > Great... but Win32 is very needed. ;-) Apparently not :_) ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Ummmm... anyone know why this doesn't work...
> Tabbing through controls is handled in DefDialogProc() when 1) dialog is > modal or 2) you call IsDialogMessage() explicitly. I have no idea how to > implement this when the buttons are inserted into a window of another > class (when DefDialogProc is not the window procedure); certainly it is > possible somehow. An option is to trap keypress messages and do the > tabbing yourself. Actually, it's 'TranslateMessage' that is causing the problem. >From the WinSDK helpfile: "The TranslateMessage function translates virtual-key messages into character messages. The character messages are posted to the calling thread's message queue, to be read the next time the thread calls the GetMessage or PeekMessage function." It is therefore removing the VK_TAB from the message the Button etc sends. This is needed to implement the WS_TABSTOP functionality. I've tested this in a framework I have been tinkering with (multithreaded widget framework, each window has it's own thread, as does the application instance) and it solved the lack of tabstop immediately. If you're interested I can send you the source to look at, though it's in a bit of a strange state at the moment die to me hacking it to solve the above probelm (without initially knowing how to.) Matt ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Synapse for FPC
> > Sure, but Borland is home for Synapse. > Also for FPC. See FPC as yet another Delphi version to support. If you > do a large Delphi product that will compile with a lot of versions, you > have to make adaptations also. But is is not easy! I create my code on Delphi3, and it working on all higher versions without any modification! It is same for Kylixes! I have only one version of sources, and this sources working under Kylix with very small modifications. It is very easy! When I porting Synapse into FPC, then i find lot of incompatibilities between Win32FPC and LinuxFPC. For example, look to Kylix sysutils.pas... in FPC is not here lot of stuffs! Some stuffs is in another units, some stuffs is missing at all. This is very bad situation for create programs for Delphi and FPC! > I'm thinking about > - dividing stuff over files (units, includefiles), so that alternate > versions can be added for other os/processor/version/ I know. I only not need this yet. That is all. And redesign of this huge library needs a time. > Note that I am talking about all those defined types and constants in the > source, _NOT_ that you should use the actual functions in unit sockets. When you ask me why I using my sockets definitions instead another one? Because lot of delphi versions have this definition file different! It is strange, because then I must use lot of INDEFS. Additionally Borlands files not have IPv6 stuffs, it not supporting Winsock2 level properly, etc. I create my own definitions what working on all supported platforms and it create exactly same socket interface for all supported platforms. (for example, It provide WSAStartp function for Linux platform. Socket developing on both platform is exacly same by my synsock.pas. ;-)) -- Lukas Gebauer. E-mail: [EMAIL PROTECTED] http://www.ararat.cz/synapse/ - Ararat Synapse - TCP/IP Lib. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Re[2]: [fpc-pascal]Synapse for FPC
> Hmm, I think this is more due to the move to event driven programming models > than cooperative multitasking. No, that is a hlf truth. Have you ever tried to write blocking tcp/ip code without threads? It will block untill it receives the response. This *completely* stops the flow of the application, be it DOS, WinAPI, VCL, or some exotic home brew GUI toolkit. Now consider M$ Windows 3.1. It had no threaded capability and only very crude methods for yielding to other processes. This is the reason that M$ opted for non-blocking api, and the fact that it eased the event driven model was a bonus rather than a goal. If your app on Win3.1 didn't yield to other processes, you locked Windows. It wasn't common, but I do remember using Netscape 2 under Windows for Workgroups at University, and it was quite easy to lock the 3.11 when doing large downloads etc. This is why we all went to the Sparc labs ;-) Matt ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Synapse for FPC
> When I porting Synapse into FPC, then i find lot of incompatibilities > between Win32FPC and LinuxFPC. For example, look to Kylix > sysutils.pas... in FPC is not here lot of stuffs! Some stuffs is in > another units, some stuffs is missing at all. This is very bad > situation for create programs for Delphi and FPC! Strings.pp for example holds a lot of string related functions that really need to be in sysutils now. This is a topic that has already been noted. I think it's a time related problem - the developers have no time to alter what they see as a perfectly normal layout. The problem is that the unit structure has changed between Turbo Pascal and Delphi, but FPC tends to keep the TP structure, or invent it's own scheme. This is something I hope that 1.1 or 1.2 will address!! > I know. I only not need this yet. That is all. And redesign of this > huge library needs a time. I believe that FPC is in the wrong in many ways. FPC would be a lot easier to support if it stuck to a single Object Pascal target and dialect. This is also a point that I've brought up in the past. As for TCP/IP implementations on differing platforms - surely providing a uniform interface for FPC would solve this (IIRC that was the idea) and this could then be wrapped into a Delphi alike interface for use by Synapse etc. Even better, without any alterations, I would hope that VCL style implementations would simple seamlessly compile using the wrapper. Matt ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Synapse for FPC
On Wed, 23 Jul 2003, Matt Emson wrote: > > When I porting Synapse into FPC, then i find lot of incompatibilities > > between Win32FPC and LinuxFPC. For example, look to Kylix > > sysutils.pas... in FPC is not here lot of stuffs! Some stuffs is in > > another units, some stuffs is missing at all. This is very bad > > situation for create programs for Delphi and FPC! > > Strings.pp for example holds a lot of string related functions that really > need to be in sysutils now. They are shared. What exists in as ansistring code in strings is also in sysutils. > > This is a topic that has already been noted. I think it's a time related > problem - the developers have no time to alter what they see as a perfectly > normal layout. The problem is that the unit structure has changed between > Turbo Pascal and Delphi, but FPC tends to keep the TP structure, or invent > it's own scheme. This is something I hope that 1.1 or 1.2 will address!! We do not invent our own scheme: We have TP units and Delphi units. The TP units are nearly perfect, because TP doesn't change any more. The Delphi units were started in the time that D3 was still the current version, but meanwhile D7 is out and D8 expected, and the units change sometimes wildly. We simply cannot keep up. > > I know. I only not need this yet. That is all. And redesign of this > > huge library needs a time. > > I believe that FPC is in the wrong in many ways. FPC would be a lot easier > to support if it stuck to a single Object Pascal target and dialect. This is > also a point that I've brought up in the past. This is not correct. The TP object model/language is finished - again, because TP doesn't change. So we have no work on that any more. Now, the Delphi language compatibility is being worked on. There the situation is more complex as Delphi itself still changes. What is more, there has been feature overlap: FPC had features that delphi didn't have, and vice versa. Borland seemed to take pleasure in implementing something that already existed in FPC in a different way in Delphi. > As for TCP/IP implementations on differing platforms - surely providing a > uniform interface for FPC would solve this (IIRC that was the idea) and this > could then be wrapped into a Delphi alike interface for use by Synapse etc. It exists. See ssockets.pp in the FCL. > Even better, without any alterations, I would hope that VCL style > implementations would simple seamlessly compile using the wrapper. ICS of Francois Piette - with some minor patches - compiles using FPC. Synapse as well. The changes have been quite minor - even some potential bugs in Synapse were discovered and solved. So finally, I don't think we're doing a bad job. We'll get there, slowly but surely. Michael. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Re[2]: [fpc-pascal]Synapse for FPC
>
> > Hmm, I think this is more due to the move to event driven programming
> models
> > than cooperative multitasking.
>
> No, that is a hlf truth. Have you ever tried to write blocking tcp/ip code
> without threads?
Yes.
> It will block untill it receives the response. This completely* stops the
> *flow of the application, be it DOS, WinAPI, VCL, or
> some exotic home brew GUI toolkit.
But under Dos you would do simple polling, since the eventloop of your own.
The rest is event driven. (Dos can also be eventdriven, e.g. Turbo Vision,
but the eventloop is under your control)
E.g.
repeat
a:=select(...); //block but maximal n msec.
if (a) Then // if a not timed out
Event:=TranslateTCPIPEvent(A)
else
Event:=PollEventKeyBoardMouse();
If Event=filled Then
Dispatchevent(Event);
{$ifdef Win31}
ProcessMessages():
{$endif}
until Event=quit;
While with most other OSes/toolkits the OS/toolkit has the eventloop, and
you only provide callbacks and msghooks.
> Now consider M$ Windows 3.1. It had no threaded capability and only very
> crude methods for yielding to other processes. This is the reason that M$
> opted for non-blocking api, and the fact that it eased the event driven
> model was a bonus rather than a goal.
But TCP/IP and blocking/non-blocking existed before Windows (and probably
will exist after). Maybe win3.1 that had some effect on the Windows api,
but not on TCP/IP as a whole.
> If your app on Win3.1 didn't yield to other processes, you locked Windows.
This means that your app can't be 100% blocking. However that doesn't mean
you need to have threads. You app must deblock once every second or so and
process messages/yield.
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Synapse for FPC
> > Even better, without any alterations, I would hope that VCL style > > implementations would simple seamlessly compile using the wrapper. > > ICS of Francois Piette - with some minor patches - compiles using FPC. > Synapse as well. The changes have been quite minor - even some potential > bugs in Synapse were discovered and solved. ICS suffers from the same (though relatively minor) problems as Synapse, Jedi's JCL have similar problems: - Defines and ifdefs need a generic rework, Delphi versions IFDEF'ing need to be generalised. Not working directly on versions, but on capabilities. So in your actual source you should never directly test Delphi or Kylix values. Test that in a central include file, and then work with HAS_INTERFACES to encapsulate code that needs interfaces etc. - Separation of OS platform and x86 dependant behaviour. - That also affects the "uses" clauses a lot. Some of these packages import wintypes,winprocs (IIRC ICS because it is still D1 compat) - Some functions typing need to be fixed. > So finally, I don't think we're doing a bad job. We'll get there, slowly > but surely. Certainly. The problem is that all of the above things are minor work if you are aware of these issues, and the source is gradually adapted along these lines while working on it (while working on normal revisions, e.g. for Kylix and Delphi) They are a lot of work if you have to fix everything at once later on, to support FPC, or an additional FPC target, and that makes FPC look bad unnecessarily. Nobody says a package should change in one day. FPC doesn't neither. E.g. FreeBSD support came only in, in 1.0.2, and see how far we have come with that in 1.0.10. The 1.1 branch (2.0 release in time) is even more important in that respect, since it will make the base units much more platform independant, with less hacks, so that generic wrappers can be easier implemented on top. The important thing to remember is that making an inventory what's fundamentally wrong now, and then acting upon it in the long run is a really a lot less work then trying to fix everything at once. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Synapse for FPC
> So finally, I don't think we're doing a bad job. We'll get there, slowly > but surely. You're all doing a good job, I was just pointing out that these are not new issues. > > Strings.pp for example holds a lot of string related functions that really > > need to be in sysutils now. > > They are shared. > What exists in as ansistring code in strings is also in sysutils. Why does this need to exist in two places? This is not helpful. The truth is, I have no right to complain. I'm perfectly capable of using FPC as is. It's the people that come to you from other sources that seem to be confused (ex-TP people especially.) Maybe FPC would be simpler if it was 2 or 3 exe's. e.g. fpc_tp[.exe], fpc_obj[.exe] and fpc_bd[.exe]. I include an fpc_obj to be polite as I see no real need for it. I made my opinion of the obj fpc made clear a long time ago ;-) > > This is a topic that has already been noted. I think it's a time related > > problem - the developers have no time to alter what they see as a perfectly > > normal layout. The problem is that the unit structure has changed between > > Turbo Pascal and Delphi, but FPC tends to keep the TP structure, or invent > > it's own scheme. This is something I hope that 1.1 or 1.2 will address!! > > We do not invent our own scheme: You don't follow the Borland one. This is therefre your own scheme. A mix between Delphi and TP. > We have TP units and Delphi units. The TP units are nearly perfect, > because TP doesn't change any more. The Delphi units were started in the > time that D3 was still the current version, but meanwhile D7 is out and > D8 expected, and the units change sometimes wildly. We simply cannot > keep up. LOL!!! I've been using Delphi since v1. This is a complete exageration. Between D2 and D5 the unit changes are minor. D6+ granted, there are a excess of new units, and some things change wildly, but in 90% of cases where new language features and routines are not being used, the *only* change needed is the removal of the 'variants' unit from the uses clause of D6+ projects. This is proven by the fact that Synapse Delphi examples are all Delphi 7 projects, and all I needed to do was accept the compaint from the IDE about properties not existing and remove 'Variants' to compile under D5. You should aim for D5. Most large corperations are still using D5. We will not move to D7, we are waiting for D8 for the dotNET implementation. Even then, we will likely leave some of our legacy systems in D5. As for language features. Borland got it right in many places that FPC didn't. Explicit overloading is an example of this. The only thing I see FPC has over Delphi still, is operator overloading. Even then I wonder if I really need that feature. > > > I know. I only not need this yet. That is all. And redesign of this > > > huge library needs a time. > > > > I believe that FPC is in the wrong in many ways. FPC would be a lot easier > > to support if it stuck to a single Object Pascal target and dialect. This is > > also a point that I've brought up in the past. > > This is not correct. The TP object model/language is finished - again, > because TP doesn't change. So we have no work on that any more. I won't ask why TP is still supported because it will doubtless start a flamewar. I don't understand though. Have you looked in "Borland.public.turbopascal" recently? Not exactly the busiest community ever. > Now, the Delphi language compatibility is being worked on. There the > situation is more complex as Delphi itself still changes. What is more, > there has been feature overlap: FPC had features that delphi didn't > have, and vice versa. Borland seemed to take pleasure in implementing > something that already existed in FPC in a different way in Delphi. > > > As for TCP/IP implementations on differing platforms - surely providing a > > uniform interface for FPC would solve this (IIRC that was the idea) and this > > could then be wrapped into a Delphi alike interface for use by Synapse etc. > > It exists. See ssockets.pp in the FCL. I assumed as much. Matt ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Synapse for FPC
On Wed, 23 Jul 2003, Matt Emson wrote: > > > So finally, I don't think we're doing a bad job. We'll get there, slowly > > but surely. > > You're all doing a good job, I was just pointing out that these are not new > issues. > > > > Strings.pp for example holds a lot of string related functions that > really > > > need to be in sysutils now. > > > > They are shared. > > What exists in as ansistring code in strings is also in sysutils. > > Why does this need to exist in two places? This is not helpful. Because strings already existed in TP. Delphi merged several 'old' tp units into one: DOS/Strings -> sysutils. > > The truth is, I have no right to complain. I'm perfectly capable of using > FPC as is. It's the people that come to you from other sources that seem to > be confused (ex-TP people especially.) > > Maybe FPC would be simpler if it was 2 or 3 exe's. e.g. fpc_tp[.exe], > fpc_obj[.exe] and fpc_bd[.exe]. I include an fpc_obj to be polite as I see > no real need for it. I made my opinion of the obj fpc made clear a long time > ago ;-) > > > > This is a topic that has already been noted. I think it's a time related > > > problem - the developers have no time to alter what they see as a > perfectly > > > normal layout. The problem is that the unit structure has changed > between > > > Turbo Pascal and Delphi, but FPC tends to keep the TP structure, or > invent > > > it's own scheme. This is something I hope that 1.1 or 1.2 will address!! > > > > We do not invent our own scheme: > > You don't follow the Borland one. This is therefre your own scheme. A mix > between Delphi and TP. We _do_ follow Borland's one, just they have two schemes, separated in time. We also have two schemes, but not separated in time. > > > We have TP units and Delphi units. The TP units are nearly perfect, > > because TP doesn't change any more. The Delphi units were started in the > > time that D3 was still the current version, but meanwhile D7 is out and > > D8 expected, and the units change sometimes wildly. We simply cannot > > keep up. > > LOL!!! I've been using Delphi since v1. This is a complete exageration. > Between D2 and D5 the unit changes are minor. Have a look at db.pas. > D6+ granted, there are a > excess of new units, and some things change wildly, but in 90% of cases > where new language features and routines are not being used, the *only* > change needed is the removal of the 'variants' unit from the uses clause of > D6+ projects. This is proven by the fact that Synapse Delphi examples are > all Delphi 7 projects, and all I needed to do was accept the compaint from > the IDE about properties not existing and remove 'Variants' to compile under > D5. This is not 'minor'. e.g. all code setting these 'new' properties would have to be removed. For a small demo app, this is unlikely to happen, but in a large project with about 126.000 lines of implementation code, it can be painstaking... But I agree that Borland tries to keep backward compatible. And rightly so. > > You should aim for D5. Most large corperations are still using D5. So do I. > We will > not move to D7, we are waiting for D8 for the dotNET implementation. Even > then, we will likely leave some of our legacy systems in D5. > > As for language features. Borland got it right in many places that FPC > didn't. This is highly a matter of taste and preference. > Explicit overloading is an example of this. The only thing I see FPC > has over Delphi still, is operator overloading. Even then I wonder if I > really need that feature. You don't need overloading either, just as you don't need exceptions and classes and interfaces. This is a matter of taste... > > > > > I know. I only not need this yet. That is all. And redesign of this > > > > huge library needs a time. > > > > > > I believe that FPC is in the wrong in many ways. FPC would be a lot > easier > > > to support if it stuck to a single Object Pascal target and dialect. > This is > > > also a point that I've brought up in the past. > > > > This is not correct. The TP object model/language is finished - again, > > because TP doesn't change. So we have no work on that any more. > > I won't ask why TP is still supported because it will doubtless start a > flamewar. I don't understand though. Have you looked in > "Borland.public.turbopascal" recently? Not exactly the busiest community > ever. Maybe so, but there are still a lot of old projects or code snippets that people made, and which can be compiled with FPC to be reused again. The number of times that I get a message from someone thanking us that we keep fpc compiling TP code e.g. on linux is more than enough justification for keeping the different modes and language options. But rest assured, I don't program TP code, I program Delphi code, as I think it is more 'right'. Michael. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Re[2]: [fpc-pascal]Synapse for FPC
> But under Dos you would do simple polling, since the eventloop of your own. > The rest is event driven. (Dos can also be eventdriven, e.g. Turbo Vision, > but the eventloop is under your control) Yes, but doing that in DOS was not trivial. Where as in UNIX it's just a fork away. > While with most other OSes/toolkits the OS/toolkit has the eventloop, and > you only provide callbacks and msghooks. Yes, but most other moder OS/Toolkits run on top of a mutitasking kernel. If you're lucky it's preemptive. That wasn't always the case. > > Now consider M$ Windows 3.1. It had no threaded capability and only very > > crude methods for yielding to other processes. This is the reason that M$ > > opted for non-blocking api, and the fact that it eased the event driven > > model was a bonus rather than a goal. > > But TCP/IP and blocking/non-blocking existed before Windows (and probably > will exist after). Maybe win3.1 that had some effect on the Windows api, > but not on TCP/IP as a whole. Never said M$ invented it. Just said that it came about on small OS (small as opposed to large commercial OS of the 70's like UNIX) because the OS as they were could not handle blocking TCP/IP. > > If your app on Win3.1 didn't yield to other processes, you locked Windows. > > This means that your app can't be 100% blocking. However that doesn't mean > you need to have threads. You app must deblock once every second or so and > process messages/yield. Yes. This is how non-blocking api's work, in essence. Surely this is a circular argument? Matt ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Ummmm... anyone know why this doesn't work...
In reply to your message of July 23, 2003 > The answer is simple, but very illusive!!! > while (GetMessage(wmsg, FWindowHandle, 0, 0)) do begin > if not ( IsDialogMessage(FWindowHandle, wmsg) ) then ///this is the > line you nees to add > TranslateMessage(wmsg); > DispatchMessage(wmsg); > end; > If you look at what TranslateMessage actually does it all becomes clear. THANKS! ... I never would have stumbled on that one without some help. The final version is this: while GetMessage(@oMsg,0, 0, 0) do begin if not (IsDialogMessage(OHandle,omsg)) then begin TranslateMessage(oMsg); DispatchMessage(oMsg); end; end; I had to bracket both translatemessage and dispatchmessage before it would work. Now the ws_group and ws_defpushbutton work too. - L D Blake ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Synapse for FPC
> > > Sure, but Borland is home for Synapse. > > Also for FPC. See FPC as yet another Delphi version to support. If you > > do a large Delphi product that will compile with a lot of versions, you > > have to make adaptations also. > > But is is not easy! I create my code on Delphi3, and it working on > all higher versions without any modification! And does it work on lower versions without any modification? Otherwise you still don't support multiple versions. > It is same for Kylixes! > I have only one version of sources, and this sources working under > Kylix with very small modifications. It is very easy! Hmm, I actually saw a lot of ifdef linux in synapse :-) More than ever will be needed for e.g. FPC/win32 :-) > When I porting Synapse into FPC, then i find lot of incompatibilities > between Win32FPC and LinuxFPC. For example, look to Kylix > sysutils.pas... in FPC is not here lot of stuffs! Stuff that was there in D3? Don't forget that basically the _fixes_ (1.0.x) branch delphi compability is roughly D2-D4 level! (though michael added quite some later stuff from time to time from later 1.0.x versions) > Some stuffs is in another units, some stuffs is missing at all. This is > very bad situation for create programs for Delphi and FPC! If it is missing, and it is not because of it being somewhat platform dependant, it is because it is not implemented _for_ delphi mode yet. Also keep in mind that FPC is aiming for much more platforms than Delphi ever will. That's a strength of FPC, but no strength comes without compromises. FPC therefore can't work around certain issues that Borland still can. If you want FPC (and non win32 and linux targets) you will have to think about those issues. Adding features (including extra targets) always needs an investment, there is no free ride, exactly like that you often need to ifdef linux for Kylix too. The FPC core team tries to minimalise this, but to fully take advantage of this, you have to adapt some of the mindset, and the minimalisation of work is meant to yield the solution that requires the least work _in the long run_. We have no other choice, since we all have day jobs. We can't quickly invest a lot of time in some temporary work arounds, and sell you the next workaround as a new version next year like Borland can. The attitude of a 3rd party library builder towards us simply has to be different. You are not our customer in the same way you are Borlands. That has disadvantages (we can't make it always easy for you, e.g. if it hampers long time development, and fully commit ourselves to every hype-of-the-day, which is why there is no FPC.NET yet) But there are also advantages: - short communication lines. You talk directly to the developpers, and when reasonable, your fixes will be quickly absorbed. - (useful for third party library creators) Most users use the most recent version, or the version before that, and usually upgrade within a year after a certain release. (1.0.2 usage is nihil, 1.0.4 low) Simply because they don't have to _buy_ the upgrade, and we don't support more than one or two (two if there is a major version difference) versions. - We design FPC so that your codebase will be high quality long term, not just to convince you to upgrade to the next version quickly. I think at the time we are at the second release of the 1.1 branch, (so 2.0.2 or so) most of the growth will have happened, and our lagging behind will end for the base libraries (RTL, FCL etc). But we will have that on a lot of systems and architectures. Some of this might sound negative towards Borland. It isn't meant to. It's Borlands business model, and you essentially pay them to adapt and tackle such issues quickly. > > I'm thinking about > > - dividing stuff over files (units, includefiles), so that alternate > > versions can be added for other os/processor/version/ > > I know. I only not need this yet. That is all. And redesign of this > huge library needs a time. Good. That's an important realisation. All my criticism is meant long-term. I compiled a lot of Delphi stuff with FPC, mainly to test the 1.1.x compiler compability (ICS, Decal, Jedi win32 headers, Jedi JCL, and some more), and the issues are always the same. So try to grasp the mindset of the combination of multi-platform FPC development and Delphi, and then try to slowly morph to that vision, simply by making changes from time to time, and if you have to revise a particular part of the code, revise it so that it is more compatible with FPC. I'd aim for convergence near the time when we are starting to finalise the 1.1.x branch for release. I wouldn't spend to much time achieving compability with 1.0.x, since a lot will change in 1.1. However the basic principles of making a source somewhat compiler, processor and OS agnostic and building a infrastructure for that are universal. > > Note that I am talking about all those defined types and constants in the > > sourc
Re: [fpc-pascal]Ummmm... anyone know why this doesn't work...
> In reply to your message of July 23, 2003 > > > > The answer is simple, but very illusive!!! > > > while (GetMessage(wmsg, FWindowHandle, 0, 0)) do begin > > if not ( IsDialogMessage(FWindowHandle, wmsg) ) then ///this is the > > line you nees to add > > TranslateMessage(wmsg); > > DispatchMessage(wmsg); > > end; > > > If you look at what TranslateMessage actually does it all becomes clear. > > > THANKS! ... I never would have stumbled on that one without some help. Cool. I'll amend my code too. It semed to work fine with the DispatchMessage still available, but I'm using multiple threads and a hack to get the compiler to treat methods as callback procs, so that could be the reason. It was a pleasure because it stumped me too, to begin with ;-) Matt ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Synapse for FPC
> Because strings already existed in TP. > Delphi merged several 'old' tp units into one: DOS/Strings -> sysutils. You only therfore need sysutils, *or* the old scheme. Not both. I understand why this was done by Borland. Legacy is hard to break, and D1 broke with legacy. > > You don't follow the Borland one. This is therefre your own scheme. A mix > > between Delphi and TP. > > We _do_ follow Borland's one, just they have two schemes, separated in time. > > We also have two schemes, but not separated in time. And therefore your own scheme. It's not the current, nor the old, but a hybrid on the Windows platform, and on the Linux/BSD platform I expect you *do* have some of your own scheme in place, I have never looked. > > LOL!!! I've been using Delphi since v1. This is a complete exageration. > > Between D2 and D5 the unit changes are minor. > > Have a look at db.pas. The truth is, I have ported extermely large apps from D1 to Delphi 3 and 4. There is no significant problem, so long as you didn't do nasty hacky things with the implementation of TTable etc. Class hierarchies have changed, but this should and does not matter. The code, so long as it does not break any rules, still compiles. D1 was the biggest DB change, and D1 apps are fairly trivial to convert to D3, so long as you respect the language features that have changed. From D2 to D5 is pretty straight froward too. > This is not 'minor'. e.g. all code setting these 'new' properties would have > to be removed. For a small demo app, this is unlikely to happen, but in > a large project with about 126.000 lines of implementation code, it can > be painstaking... The IDE will remove all unknown properties from the DFM when streaming it in. The rest is accademical. Most properties that have been introduced are to do with support for unicode and bidirectional languages. Borland are very good at not adding nasty additional features. It's thrid parties that usually excel at that. > But I agree that Borland tries to keep backward compatible. And rightly > so. If you mainly use native Borland VCL components, the transistion from D2 to D5 is fairly trivial. The migration from D7 back to D5 is also trivial, although you will run into incompatibilities due to language features that have been added (the new $if and enum types that allow indexes to be specified being two that crop up frequently.) I've ported Dave Jewels GDI+ examples from the Delphi Magazine to Delphi 5, and he uses just about every new feature he can find. That was pretty trivial. > This is highly a matter of taste and preference. > > > Explicit overloading is an example of this. The only thing I see FPC > > has over Delphi still, is operator overloading. Even then I wonder if I > > really need that feature. > > You don't need overloading either, just as you don't need exceptions and > classes and interfaces. This is a matter of taste... Sure. Overloading should be used sparingly (as James Mills proved last week.) Exceptions are needed. Classes are needed. Interfaces are usefull. Not my taste, just a fact. They are too well established not to argue on. > Maybe so, but there are still a lot of old projects or code snippets > that people made, and which can be compiled with FPC to be reused again. Any many more that do not work due to the flat 32bit memory architecture. That's a bit like saying "I can use COBOL.Net to compile my old mainframe apps for Windows." Maybe even like saying "I can recompile my old VB6 apps in VB.Net." ;-) > The number of times that I get a message from someone thanking us that > we keep fpc compiling TP code e.g. on linux is more than enough > justification for keeping the different modes and language options. Sure. But you could create a 'TP' branch of the compiler, remove it from the main compiler soure tree and leave it for the legacy peeps. If you got the seperation right, you could still share sections of the engine, just not the code parser and such. This would then focus FPC on the here and now, and you could remove the legacy from the unit tree. > But rest assured, I don't program TP code, I program Delphi code, as I > think it is more 'right'. You got my vote ;-) Matt ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Synapse for FPC
> > But is is not easy! I create my code on Delphi3, and it working on > > all higher versions without any modification! > > And does it work on lower versions without any modification? Otherwise > you still don't support multiple versions. Delphi 1 would be unlikely. Delphi 2 was an awful compiler, (roughly a hacked Delphi 1 that supported 32bit development, but through partial emulation iirc) and was never really used by a lot of hardcore dev's. Delphi 3 is regarded as the lowest common denominator by most Delphi programmers these days. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Synapse for FPC
On woensdag, jul 23, 2003, at 16:46 Europe/Brussels, Matt Emson wrote: You only therfore need sysutils, *or* the old scheme. Not both. You do need both if you advertise both TP and Delphi compatibility. Jonas ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Synapse for FPC
[some minor remarks] > Maybe FPC would be simpler if it was 2 or 3 exe's. e.g. fpc_tp[.exe], > fpc_obj[.exe] and fpc_bd[.exe]. I include an fpc_obj to be polite as I see > no real need for it. I made my opinion of the obj fpc made clear a long time > ago ;-) Opinions differ. But the IDE and parts of the compiler itself are TP. If we had a lot of hard working people, we could make a nice new set of platform dependant units, and more and more TP units would become legacy. Do you volunteer? > perfectly > > > normal layout. The problem is that the unit structure has changed > between > > > Turbo Pascal and Delphi, but FPC tends to keep the TP structure, or > invent > > > it's own scheme. This is something I hope that 1.1 or 1.2 will address!! > > > > We do not invent our own scheme: > > You don't follow the Borland one. We do in general. But 1.0.x is frozen, and we have to make adjustments for the fact that we have a strict visual<-> non visual separation, and a lot more platforms (and processors in the near future). Giving that up is no option. It is the main edge that FPC has over Borland, except the doubtful one that it is free. > This is therefre your own scheme. A mix between Delphi and TP. No it isn't. It is roughly a superset of Delphi and TP, so also a superset over Borlands scheme. > > We have TP units and Delphi units. The TP units are nearly perfect, > > because TP doesn't change any more. The Delphi units were started in the > > time that D3 was still the current version, but meanwhile D7 is out and > > D8 expected, and the units change sometimes wildly. We simply cannot > > keep up. > > LOL!!! I've been using Delphi since v1. This is a complete exageration. > Between D2 and D5 the unit changes are minor. So ansistrings, widestrings, dynamic arrays etc changes are minor? How many differences are there inside the core units (like sysutils) compared to e.g. D3? What are the deviances of FPC except adding a few extra units, and putting some platform dependant stuff in extra units? > D6+ granted, there are a excess of new units, and some things change > wildly, but in 90% of cases where new language features and routines are > not being used, the *only* change needed is the removal of the 'variants' > unit from the uses clause of D6+ projects. Try to compile something from Jedi. They still support D5, but I sometimes wonder how long. FPC is still getting more compatible to newer Delphi's fast, I don't really see the problem. > This is proven by the fact that Synapse Delphi examples are all Delphi 7 > projects, and all I needed to do was accept the compaint from the IDE > about properties not existing and remove 'Variants' to compile under D5. The synapse author already said in this thread that Synapse is a suite that already exists for a couple of Delphi versions. > You should aim for D5. Most large corperations are still using D5. We will > not move to D7, we are waiting for D8 for the dotNET implementation. Even > then, we will likely leave some of our legacy systems in D5. This is not common IMHO. While in my surroundings there are indeed a lot of people/companies that don't upgrade, I don't see a firm separation somewhere between D5 and D6+. > As for language features. Borland got it right in many places that FPC > didn't. Explicit overloading is an example of this. The only thing I see > FPC has over Delphi still, is operator overloading. Even then I wonder if > I really need that feature. I don't understand all this. Sure, FPC is lagging behind in features, but "Borland got it right in many places that FPC didn't". Where does this come from? > > > also a point that I've brought up in the past. > > > > This is not correct. The TP object model/language is finished - again, > > because TP doesn't change. So we have no work on that any more. > > I won't ask why TP is still supported because it will doubtless start a > flamewar. I don't understand though. Have you looked in > "Borland.public.turbopascal" recently? Not exactly the busiest community > ever. Simple. We are not a major vendor, but providing a suite for a certain niche (roughly people with Borland affinities and demands that are not met by Borlands current product lines. Think portability, legacy, total access to source including compiler etc, e.g. because of embedded world). That and the Open Source price advantage are our only plusses over Borland. So if it is a from a worldwide IT perspective, it doesn't have to be a niche for us. We are already a niche :-) There are of course also historical reasons. The compiler is already Delphi compatible The only way to improve the situation is more collaborators, and/or a much higher users that e.g. occasionally does some work for FPC (update a certain unit, make an interface etc). The situation nowadays is already much better than it used to though say a few years back, on the other hand, there is a lot more to do nowadays too. __
Re: [fpc-pascal]Synapse for FPC
> On woensdag, jul 23, 2003, at 16:46 Europe/Brussels, Matt Emson wrote: > > > You only therfore need sysutils, *or* the old scheme. Not both. > > You do need both if you advertise both TP and Delphi compatibility. Use aliases for sysutils. That or aliases in Delphi mode for strings, dos etc. Matt ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Synapse for FPC
On woensdag, jul 23, 2003, at 17:04 Europe/Brussels, Matt Emson wrote: Use aliases for sysutils. That or aliases in Delphi mode for strings, dos etc. That's kind of hard to do if you don't support aliases yet. We may support them now, but we most certainly did not support them when those units were written. Jonas ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Synapse for FPC
In reply to your message of July 23, 2003 > If we had a lot of hard working people, we could make a nice new set of > platform dependant units, and more and more TP units would become legacy. This is a truly interesting discussion, I hope you don't mind a few comments from someone who's just now re-joining the programming game, as retirement approaches... On the subject of Strings and on a strictly personal note: I would prefer a language that is tightly integrated with an OS... so tightly that OS calls and language calls fit together in one smooth flow. I should not have to translate strings or use trickery like "A := B+A+#0" or "@A[1]" to get things to work. OS calls should be so seamless as to appear to be part of the language, not part of yet another complex bag of tricks that has to be studied and understood. I'm not saying you should mask API calls to make them look like Pascal syntax. Just the opposite, I'm thinking it might be better to bend Pascal to work better with the OS... Make it natively work with null terminated strings in windows, give it the same numerical structures as BEOS, support LINUX file handling in Pascal's normal file handlers, etc. Source code portability is a wonderful idea, but not at the expense of speed or power in the language. As a one time professional software developer, I'd rather write highly specific code that works flawlessly than have to mangle and mask things to get stuff to work. I do understand the need for cross-platform developement, especially with Linux nipping at Window's heels these days... but I would rather have to run a source code converter program once to switch platforms than to always run string, math and file converters on the platform I'm using... Just my 2 cents worth... - L D Blake ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Synapse for FPC
> > But is is not easy! I create my code on Delphi3, and it working on > > all higher versions without any modification! > And does it work on lower versions without any modification? Otherwise > you still don't support multiple versions. what? I support Delphi 3, 4, 5, 6 and 7... is is not multiple versions? And for this support I not need any IFDEFS! I maybe also supports Delphi 2, but I not tested this for long time, I cannot confirm this. I cannot support Delphi 1, because delphi 1 is for ANOTHER operating system platform. (It is for Win16, not for Win32!) > > It is same for Kylixes! > > I have only one version of sources, and this sources working under > > Kylix with very small modifications. It is very easy! > Hmm, I actually saw a lot of ifdef linux in synapse :-) More than ever > will be needed for e.g. FPC/win32 :-) Look to this deeply. Lot of LINUX IFDEFS is for FPC! Otherwise LINUX IFDEFS is in synsock.pas, because this unit hides platform differents on sockets for rest of my library. Other IFDEFS is minor! (and this is for huge platform differents, for example: Linux compute checksum of ICMPv6, but under Windows must compute by your hands...etc. Sorry, but create special library for platform independent ICMPv6 checksum computing is not right way.. it only create tons of other units... ;-() > > When I porting Synapse into FPC, then i find lot of incompatibilities > > between Win32FPC and LinuxFPC. For example, look to Kylix > > sysutils.pas... in FPC is not here lot of stuffs! > Stuff that was there in D3? Don't forget that basically the _fixes_ (1.0.x) > branch delphi compability is roughly D2-D4 level! (though michael added > quite some later stuff from time to time from later 1.0.x versions) I know, some stuffs from newer versions is added by my requests. ;-))) But when I porting Synapse to FPC, I found lot of incompatibilities with my D3 (and with all higher versiopns of Delphi too!)... For little example: On Delphi workd exists structure TSystemTime. Thjis is defined in Windows.pas, and all related time functions on delphi using this structure. For example, lot of functions inside sysutils.pas. it allows get system time by Win32 API call and then you can handle returned value by lot of functions in Sysutils.pas. This is great... Now Look to FPC: windows.pas have one TSystemTime record... and sysutils using another TSystemTime structure. Two different structures with same name! Now I must get system time by API call, I must CONVERT IT to another structure... and then I can continue. All this and similar problems is reported by me to Michael. He really very help me with porting of Synapse by adding lot of stuffs, what is missing and I need it. > Also keep in mind that FPC is aiming for much more platforms than Delphi > ever will. That's a strength of FPC, but no strength comes without > compromises. I know, it is not easy. here is tw ways, and both is needed: 1. easy to create multipltforms programs. You need lot of platform independent units. 2. but someone not need multiplatform compatibility, they need use existing code from delphi. For delphi exists very lot of code, Delphi is biggest pascal community on world, I think. I say, multiplatform compatibility is important, but compatibility with delphi is important too! Maximum compatbility with Delphi is very strategic. > We have no other choice, since we all have day jobs. [...] I know, you not need taling me about hard live in opensource community. I am opensource developer too, I have same problems as you. ;-) [...] > I'd suggest to leave the combination of win32 and Delphi intact. FPC's > win32api can better be brought in sync with Delphi's in time, there is not > much reason not to. I would move it to use includefiles to make readability > of the synsock file a bit better. As I say here before, I PLAN to rewrite my synsock! You not need convincing me aboyt thinks what I know. ;-) I only explain here, why it is not yet rewrited. -- Lukas Gebauer. E-mail: [EMAIL PROTECTED] http://www.ararat.cz/synapse/ - Ararat Synapse - TCP/IP Lib. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
