L D Blake wrote:
I've just discovered that the MMSYSTEM unit for Win32 is missing at least one
of the function call prototypes... MCIWndCreate(...) is just plain not there.
Anyone know where I can get a fixed copy?
There is no such "fixed copy" of MMSystem unit. MMSystem unit is a
translation of
> > Core of this problems is not platform independency. Or not?
> In this particular example, the field was simply forgotton, and we'll
> add it. This is not a problem.
Great! ;-)
If I replay my discussion int very short form, then it is look as:
X> Synapse is not good, because it using lot of I
While I absolutely adore FreePascal I miss one feature from my old
borland days, but that would require a little work.
I miss being able to put the cursor on a function/procedure/reserved
word name and hitting F1 to see the help section for it. It was
wonderful for looking up the structure of a fu
In reply to your message of July 24, 2003
> Seconded.
Thirded ??
I like the compiler just fine.
I was simply suggesting some improvements for the documentation.
-
L D Blake
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal
Seconded.
Mark Emerson
Alan Mead wrote:
>
> I don't have time right now to read all the messages that flew today
> but I read enough to decide to send this note.
>
> IMHO, FPC is like a dream come true. I love the fact that I can
> compile the same code on Windows and Linux (and others). I lo
I don't have time right now to read all the messages that flew today
but I read enough to decide to send this note.
IMHO, FPC is like a dream come true. I love the fact that I can
compile the same code on Windows and Linux (and others). I love the
ways the compiler is (mostly) backwards-compat
I've just discovered that the MMSYSTEM unit for Win32 is missing at least one
of the function call prototypes... MCIWndCreate(...) is just plain not there.
Anyone know where I can get a fixed copy?
-
L D Blake
___
fpc-pascal maillist - [EMAIL
> > It's a matter of taste, but don't forget otherwise you have to
> > scroll/search through the same amount of info. I really dislike units that
> > are longer than 1000-2000 lines.
> >
> > In time Lazarus could be adapted to make things a bit easier (e.g. opening
> > all includefiles too when op
Matt Emson wrote:
Free CLX contains a large chunk of the RTL, and is already supporting Linux
and Windows.
... and it's full of terrible ifdef linux/win32 ... Can you imagine the
mess if you handle 10 or more targets this way :) ?
Almost ten years ago I started OS/2 and linux support this way an
On Thu, 24 Jul 2003 15:17:50 +0200 (CEST)
[EMAIL PROTECTED] (Marco van de Voort) wrote:
> > > You can simply make a preprocessor which does that if you find it fun
> > > to
> > do.
> > > But this doesn't change the unit structure, and gives no advantage in
> > > maintainability at all. At most the
> > As was also stated you are using the mind set of a single platform
> > development tool. FPC is not a single platform development tool and can
> > not be viewed in that fashion.
>
> But all the source is seperated isn't it ? It doesn't all reside in a single
> dir?
No. It never has, at least
In reply to your message of July 24, 2003
> Exactly. For the average joe user, it's single platform work that matters.
> You are focusing as a FPC developer, not an end user. That is why you can't
> see how unwieldy and intimidating the FPC unit structure can be if you don't
> undestand it, or if y
> Lukas - I think grep is your best friend with FPC. You need to find the
> function 'GetXXX' but don't know where it it - I usually grep for it (using
> Cygwin on Windows.) If you're not familiure with grep, some thing like:
I am using much easier way for this... I am using TotalCommander and
the
> > FPC style of coding is good for handle multiplatform sources, but for
> > me (mean program developer) is this sources very badly readable. ;-(
>
> Excuse me, but you are NOT the mean program developer. The mean program
> developer does not write a TCP/IP suite.
I not mean ''main'.. I mean 'pro
> > Michael - if none of your developers look at the Delphi source code, I
> > shudder to think at the standard of programming they produce.
>
> I am not the judge of my collegae, so allow me not to comment on this.
> But believe me if I say that they haven't looked at the sources, this is
> simply
> > > Michael - if none of your developers look at the Delphi source code, I
> > > shudder to think at the standard of programming they produce. I've never
> met
> > > a professional programmer who doesn't at least look at headers/interface
> > > sections of code to understand how a routine works.
> If you want to start such converter tool btw, you might want to look at
the
> fpdoc documentation subproject, IIRC it already contains a parser.
I think I already have a Pascal parser. I'd have to look in my personal code
lib.
I'll add it to my todo list and see what happens.
Matt
> You may not be alone but you are in a very small minority. I have been
> coding in Delphi since 1.0 and can never think of any reason why I had
> to look at the Delphi code to do my own coding. They only time I had to
> dig into it was when I wanted to determine how Delphi did something that
> I
> > Michael - if none of your developers look at the Delphi source code, I
> > shudder to think at the standard of programming they produce. I've never
met
> > a professional programmer who doesn't at least look at headers/interface
> > sections of code to understand how a routine works. Not doing
On Thu, 24 Jul 2003, Matt Emson wrote:
> Michael - if none of your developers look at the Delphi source code, I
> shudder to think at the standard of programming they produce.
I am not the judge of my collegae, so allow me not to comment on this.
But believe me if I say that they haven't looked
> | A Pascal translation of the jpg library is already included with FPC.
>
> I am afraid that this is implemented in Delphi Style?
I don't expect so. It is a straight C translation, which is not OOP by
nature.
The idea was to build classes on top of that.
> I am one of those old guys who still
On donderdag, jul 24, 2003, at 16:19 Europe/Brussels, Marco van de
Voort wrote:
What I suggested used no IFDEFS, none at all. Each platform end user
release, has a set of platform specific units created by a
preprocessor.
This would be specifically for x86/Dos, x86/Windows, x86/Solaris,
x86/BSD
Matt Emson wrote:
Michael - if none of your developers look at the Delphi source code, I
shudder to think at the standard of programming they produce. I've
never met a professional programmer who doesn't at least look at
headers/interface sections of code to understand how a routine works.
Not
> > Ifdeffing them all is simply not possible, and most system independant
> units
> > have a system independant part (header, but also utility routines etc) a
> > dependant part, and sometimes even a processor dependant part (but that
> > usually is much smaller)
>
> What I suggested used no IFDE
> Michael - if none of your developers look at the Delphi source code, I
> shudder to think at the standard of programming they produce. I've never met
> a professional programmer who doesn't at least look at headers/interface
> sections of code to understand how a routine works. Not doing so is
On Thu, 24 Jul 2003, Rainer Hantsch wrote:
> On Thu, 24 Jul 2003, Marco van de Voort wrote:
> | A Pascal translation of the jpg library is already included with FPC.
>
> I am afraid that this is implemented in Delphi Style?
>
> I am one of those old guys who still program in OOP style, so this w
In reply to your message of July 24, 2003
> In most cases, casting an ansistring as pchar will work. The only caveat is
> when Windows wants to alter the variable you pass' contenets.
> e.g.
>MessageBox( pchar(MyMessage), 'test', MB_OK);
> but not:
> GetUserName( pchar(Username), 255
On Thu, 24 Jul 2003, Marco van de Voort wrote:
| A Pascal translation of the jpg library is already included with FPC.
I am afraid that this is implemented in Delphi Style?
I am one of those old guys who still program in OOP style, so this will
possibly become somehow difficult ...
Is there some
> Ifdeffing them all is simply not possible, and most system independant
units
> have a system independant part (header, but also utility routines etc) a
> dependant part, and sometimes even a processor dependant part (but that
> usually is much smaller)
What I suggested used no IFDEFS, none at a
> I need some some functions. What I need for use this function? i must
> know unit where this function is. (for adding it into uses)
>
> On Borland, i do simple text seach on Borland sources and directly I
> can see what unit I must use.
>
> But on FPC I gen only some include unit. I must do searc
Having read this thread with interest, I feel compelled to say
something.
Very simply put, I have no care how good a piece of code is by any other
judgement. If it cannot be ported, it has already failed the most
crucial test for code.
Okay, maybe that is a bit harsh, there are obviously exceptions
On Thu, 24 Jul 2003, Lukas Gebauer wrote:
> > I meant that some people prefer include files to ifdefs. In that sense,
> > it is a matter of taste.
> >
> > If one presumes as a fact that everybody prefers single-file sources with
> > IFDEFS in it, then your statement about 'a matter of fact' is 1
> > I think they do, because the IDE does NOT support include files, so you
> simply
> > cannot work with include files and enjoy the blessings of the IDE.
> > I was told that for productivity reasons they do all development
> > in the IDE itself, so...
>
> That will be why there are a lot of mach
On Thu, 24 Jul 2003, Lukas Gebauer wrote:
> > That isn't. I was more hinting at the TSystemTime example. Sysutils is
> > platform independant, and Windows is dependant.
>
> Ok, enhance this my example: What is different between TSystemTme
> structure in sysutils and in windows? Windows structure
> > You can simply make a preprocessor which does that if you find it fun to
> do.
> > But this doesn't change the unit structure, and gives no advantage in
> > maintainability at all. At most the end user finds it easier to read the
> > sources.
>
> Your final line is the reason I mention it in t
> I meant that some people prefer include files to ifdefs. In that sense,
> it is a matter of taste.
>
> If one presumes as a fact that everybody prefers single-file sources with
> IFDEFS in it, then your statement about 'a matter of fact' is 100%
> correct, and I will not dispute it.
One my notic
> That isn't. I was more hinting at the TSystemTime example. Sysutils is
> platform independant, and Windows is dependant.
Ok, enhance this my example: What is different between TSystemTme
structure in sysutils and in windows? Windows structure have only one
additional field 'DayOfWeak'!
Why plat
On Thu, 24 Jul 2003, Matt Emson wrote:
> > It does, with the proviso that 'messy' is a very personal appreciation
> > of our file structure. I find it logical and not confusing at all.
> >
> > Keep in mind that it must be cross-platform.
> > Your remarks are focusing on the point of view of a si
> It does, with the proviso that 'messy' is a very personal appreciation
> of our file structure. I find it logical and not confusing at all.
>
> Keep in mind that it must be cross-platform.
> Your remarks are focusing on the point of view of a single platform user.
Exactly. For the average joe us
> > ??? I am using this constructs under Delphi without problems... :-O
> I don't remember ever getting it to work, but then I come from a D1
> background (way back when) so maybe I assumed it doesn't work.
On D1 not exists ansistrings and not exists setlength for strings. on
D1 is impossible do t
> > 100% platform independance is indeed often counter-productive. However
> > that isn't a good reason to don't do anything platform independant at
> > all:-)
>
> But I create tool for programmers and I hide all platform
> differencies in my tool. By my tool other programmers must not
> resolve a
On Thu, 24 Jul 2003, Matt Emson wrote:
> > On the contrary. We switched to this exactly because the opposite cannot
> > be maintained. 8 years of cross-platform experience.
>
> See below
>
> > You can simply make a preprocessor which does that if you find it fun to
> do.
> > But this doesn't cha
> On the contrary. We switched to this exactly because the opposite cannot
> be maintained. 8 years of cross-platform experience.
See below
> You can simply make a preprocessor which does that if you find it fun to
do.
> But this doesn't change the unit structure, and gives no advantage in
> main
> > FPC may let you do that, but Delphi will have an error about not passing
> > const params iirc. That or the result is garbage back from Windows.
>
> ??? I am using this constructs under Delphi without problems... :-O
I don't remember ever getting it to work, but then I come from a D1
backgroun
On Thu, 24 Jul 2003, Matt Emson wrote:
> Started a new thread because this is all getting off topic from Synapse.
>
> > Opinions differ. But the IDE and parts of the compiler itself are TP.
>
> Are there any plans to change this in future development? I, for one, like
> the idea of comiling the
> > begin
> > SetLength(Username,255);
> > GetUserName( pchar(Username), 255 );
> > Setlength(username,strlen(pchar(username));
> > end
> FPC may let you do that, but Delphi will have an error about not passing
> const params iirc. That or the result is garbage back from Windows.
??? I am using
> 100% platform independance is indeed often counter-productive. However that
> isn't a good reason to don't do anything platform independant at all:-)
But I create tool for programmers and I hide all platform
differencies in my tool. By my tool other programmers must not
resolve any platform depe
Started a new thread because this is all getting off topic from Synapse.
> Opinions differ. But the IDE and parts of the compiler itself are TP.
Are there any plans to change this in future development? I, for one, like
the idea of comiling the compiler in Delphi, but TP features are no longer
su
> What about
>
> var username:AnsiString;
>
> begin
> SetLength(Username,255);
> GetUserName( pchar(Username), 255 );
> Setlength(username,strlen(pchar(username));
> end
>
> Or does that mess up reference counts?
FPC may let you do that, but Delphi will have an error about not passing
const pa
> never had to deal with this and have absolutely no knowledge about how to do
> such things.
> Please, be so kind and help me understanding how I can use external Linux
> libraries.
>
> What I basically want to do is: Reading images into memory.
>
> Because there are so many different jpg/tif
Hello!
Because I always wrote pascal programs which required no external code, I
never had to deal with this and have absolutely no knowledge about how to do
such things.
Please, be so kind and help me understanding how I can use external Linux
libraries.
What I basically want to do is: Reading
> (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... ;-()
[ Charset ISO-8859-1 unsupported, converting... ]
> > 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
>
Lukas Gebauer wrote:
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 hand
> 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 ap
> I've sucessfully now done all this and now have the headers converted...
> I have a problem though when trying to compiling a test plugin:
Hard to say without source. Please post the sources (headers, demo program,
and maybe some readme that explains some stuff like needed xchat library
version
On Thu, 24 Jul 2003, James Mills wrote:
> 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
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/plugin
58 matches
Mail list logo
