Felipe Monteiro de Carvalho wrote:
The function already exists, is used on ported delphi libraries, we
already have a windows implementation and I don't see why not
implement it for other targets if possible.
The problem is that maybe it's possible to do AllocateHWND on other
platforms, but
On Fri, 26 Oct 2007, Stephano wrote:
From: Felipe Monteiro de Carvalho
I think there is a very partial implementation on LCLIntf unit
already. I don't think we should really try to replicate it. Lazarus
doesn't intend to replicate the Windows API.
--
Felipe Monteiro de Carvalho
From: Michael Van Canneyt
Your original question was not very clear: AllocateHwnd simply doesn't
make sense on other systems than Windows. You should specify why you
need it. After that, we can try to present you with an alternative.
If the idea is to do communication with another process,
Are there any plans to implement AllocateHWnd for Linux? It already exists
for win platform in Lazarus.
Stephano
_
To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
archives at
Stephano wrote:
Are there any plans to implement AllocateHWnd for Linux? It already
exists for win platform in Lazarus.
And there we go :(
Marc
_
To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the
Stephano wrote:
Marc Weustink wrote:
And there we go :(
Marc
Is that supposed to be an answer to the question?
No, but it is the proof to the reason why we didn't want to implement it
on win32
Marc
_
To unsubscribe:
From: Felipe Monteiro de Carvalho
I think there is a very partial implementation on LCLIntf unit
already. I don't think we should really try to replicate it. Lazarus
doesn't intend to replicate the Windows API.
--
Felipe Monteiro de Carvalho
I am asking because I recall you had a proposal for
On 10/26/07, Stephano [EMAIL PROTECTED] wrote:
Are there any plans to implement AllocateHWnd for Linux? It already exists
for win platform in Lazarus.
I think there is a very partial implementation on LCLIntf unit
already. I don't think we should really try to replicate it. Lazarus
doesn't
Marc Weustink wrote:
And there we go :(
Marc
Is that supposed to be an answer to the question?
_
To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
archives at
On 10/26/07, Stephano [EMAIL PROTECTED] wrote:
I am asking because I recall you had a proposal for that on Linux.
Umm... sorry, I think I confused it with SendMessage
AllocateHWnd isn't a Windows API, please ignore my previous e-mail.
My short answer is that I don't current have plans to
On 4/3/07, Jesus Reyes [EMAIL PROTECTED] wrote:
But that will not reduce the usability of the library?, I think the
speed is very important in graphics so is the most relevant issue,
I beliave that fpc can generate very good code, so we won´t loose much
performance. Anyway, this is something
Felipe Monteiro de Carvalho schrieb:
On 4/3/07, Jesus Reyes [EMAIL PROTECTED] wrote:
But that will not reduce the usability of the library?, I think the
speed is very important in graphics so is the most relevant issue,
I beliave that fpc can generate very good code, so we won´t loose much
PS: Btw. For my projects I really need something like AllocateHWnd at
least under windows. There are other possibilities to do it without it,
but for the moment everything's so sinmple with the patch.
I'm just wondering: why it wasn't called AllocateMessageQueue from the
beginning...
-
Hello Flávio,
I'm just wondering: why it wasn't called AllocateMessageQueue from the
beginning...
I'm not sure what you mean, what is 'AllocateMessageQueue' and how can
it help here? I'm usually working with windows and so I can go with
Delphi and there is no command like that. At least I
On 4/4/07, Christian Budde [EMAIL PROTECTED] wrote:
I'm not sure what you mean, what is 'AllocateMessageQueue' and how can
it help here?
I think he is saying that the current name of the function isn´t very
descriptive, and could have been better choosen
--
Felipe Monteiro de Carvalho
Felipe Monteiro de Carvalho schreef:
What other doubts do we have about this subject?
I spoke with Marc on irc (#lazarus-ide).
There were two open issues, for which I wanted feedback of other developers.
1. Is this cross platform (actually cross widget set) enough to warrant
implementation
On Tue, 03 Apr 2007 11:08:03 +0200
Vincent Snijders [EMAIL PROTECTED] wrote:
Felipe Monteiro de Carvalho schreef:
What other doubts do we have about this subject?
I spoke with Marc on irc (#lazarus-ide).
There were two open issues, for which I wanted feedback of other
developers.
1.
On 4/3/07, Felipe Monteiro de Carvalho
[EMAIL PROTECTED] wrote:
Further, I don´t know even on windows if just creating a TWinControl
would do it.
Something extra: My idea of implementing this as pure LCL would be
creating a TWinControl and implementing a WndProc. But the windows
interface
By the way, I would love if the IFDEF for Win32 Messages greater then
WM_USER was removed =)
Any reason to keep it ?
_
To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
archives at
Razvan Adrian Bogdan schreef:
By the way, I would love if the IFDEF for Win32 Messages greater then
WM_USER was removed =)
Any reason to keep it ?
To prevent abuse and writing unportable code.
It is better to think of portable solutions.
Vincent
Razvan Adrian Bogdan wrote:
By the way, I would love if the IFDEF for Win32 Messages greater then
WM_USER was removed =)
Any reason to keep it ?
Yes, to force us to think about a platform independent way of solving this.
Marc
Felipe Monteiro de Carvalho wrote:
On 4/3/07, Mattias Gaertner [EMAIL PROTECTED] wrote:
Can someone give a short example or point me to the right mail, where
AllocateHWnd is needed and why it must be implemented in all LCL
interfaces instead of the LCL?
[...]
Further, I don´t know even on
Felipe Monteiro de Carvalho wrote:
On 4/3/07, Mattias Gaertner [EMAIL PROTECTED] wrote:
Can someone give a short example or point me to the right mail, where
AllocateHWnd is needed and why it must be implemented in all LCL
interfaces instead of the LCL?
At some point I thougth about
On Tue, 3 Apr 2007 17:51:08 +0300
Al Boldi [EMAIL PROTECTED] wrote:
Felipe Monteiro de Carvalho wrote:
On 4/3/07, Mattias Gaertner [EMAIL PROTECTED] wrote:
Can someone give a short example or point me to the right mail,
where AllocateHWnd is needed and why it must be implemented in
On 4/3/07, Mattias Gaertner [EMAIL PROTECTED] wrote:
I got the impression, there is no short example for the need of
AllocateHWnd. The only reason seems to be making it easier to port a
special winapi IPC mechanism.
Isn´t that enougth?
Very large packages as orpheus and graphics32 rely on it,
--- Felipe Monteiro de Carvalho [EMAIL PROTECTED]
escribió:
On 4/3/07, Mattias Gaertner [EMAIL PROTECTED] wrote:
I got the impression, there is no short example for the need of
AllocateHWnd. The only reason seems to be making it easier to
port a
special winapi IPC mechanism.
Isn´t
On Tue, 3 Apr 2007 19:07:14 +0200
Felipe Monteiro de Carvalho [EMAIL PROTECTED] wrote:
On 4/3/07, Mattias Gaertner [EMAIL PROTECTED] wrote:
I got the impression, there is no short example for the need of
AllocateHWnd. The only reason seems to be making it easier to port a
special winapi
On 4/3/07, Jesus Reyes [EMAIL PROTECTED] wrote:
A couple of questions: isn't graphics32 a package that is optimized
through assembler routines? how portable would it be, in what
platforms would it work?.
That's not much relevant. I'll simply convert the asm routines to
pascal. I'll probably
--- Felipe Monteiro de Carvalho [EMAIL PROTECTED]
escribió:
On 4/3/07, Jesus Reyes [EMAIL PROTECTED] wrote:
A couple of questions: isn't graphics32 a package that is
optimized
through assembler routines? how portable would it be, in what
platforms would it work?.
That's not much
Ok, since noone answered so far I will.
Basically I think this method is very hard to be implemented on Gtk,
simply because the concept in which it is based does not exist there (
a function that can handle a generic message). And even if it is
implemented, I fail to see how it could be used at
I notice that win64's classes.pp includes stubs for AllocateHWnd and
MakeObjectInstance. Perhaps we could hear from the FPC team about
whether they plan to add these functions to other platforms.
In Delphi AllocateHWnd calls MakeObjectInstance to convert the object
method to a WindowProc callback
Hess, Philip J schreef:
Felipe's implementation, which instead stores the object method's code
and data pointers (4 bytes) in the window's user data, which is
retrieved by the actual callback function to reconstitute the object
method and call it, is cleaner and potentially cross-platform:
On 4/2/07, Vincent Snijders [EMAIL PROTECTED] wrote:
He should use SetWindowLongPtr on win64, otherwise he looses 32 bits.
SetWindowLongPtr cannot be used on win32 with fpc 2.0.4. The app will
refuse to run saying the function doesn´t exist.
My patch instead uses TWin32WidgetSet.SetWindowLong
Felipe Monteiro de Carvalho schreef:
On 4/2/07, Vincent Snijders [EMAIL PROTECTED] wrote:
He should use SetWindowLongPtr on win64, otherwise he looses 32 bits.
SetWindowLongPtr cannot be used on win32 with fpc 2.0.4. The app will
refuse to run saying the function doesn´t exist.
My patch
On 4/2/07, Hess, Philip J [EMAIL PROTECTED] wrote:
I notice that win64's classes.pp includes stubs for AllocateHWnd and
MakeObjectInstance. Perhaps we could hear from the FPC team about
whether they plan to add these functions to other platforms.
We can ask, but afaik AllocateHWnd cannot be
What other doubts do we have about this subject?
thanks,
--
Felipe Monteiro de Carvalho
_
To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
archives at
Vincent Snijders schreef:
Felipe Monteiro de Carvalho schreef:
Hello,
Any more remarks about the last patch? If not, I will send to the bug
tracker.
Of particular interrest is this idea:
Another idea here is to always call DefWindowProc. So you have to add
a IFDEF only if you want Delphi
On 3/26/07, Vincent Snijders [EMAIL PROTECTED] wrote:
I already asked the same question in the bug tracker and got some answers
there, but
not all.
Well, my answer was to create another patch which in my view solves the problem.
So, basically we are discussing another topic on the
Felipe Monteiro de Carvalho schreef:
Hello,
Any more remarks about the last patch? If not, I will send to the bug
tracker.
Of particular interrest is this idea:
Another idea here is to always call DefWindowProc. So you have to add
a IFDEF only if you want Delphi compatibility.
What do
Hello,
Any more remarks about the last patch? If not, I will send to the bug tracker.
Of particular interrest is this idea:
Another idea here is to always call DefWindowProc. So you have to add
a IFDEF only if you want Delphi compatibility.
What do you guys think?
thanks,
--
Felipe
Felipe Monteiro de Carvalho schreef:
On 3/13/07, Vincent Snijders [EMAIL PROTECTED] wrote:
I think you should use SetWindowLongPtr to be win64 safe.
I am using Widgetset.SetWindowLong, which should be win64 safe (ok, I
wasn´t using it all the time on previous patch, next one should fix
it).
Felipe Monteiro de Carvalho schreef:
On 3/13/07, Luiz Americo Pereira Camara [EMAIL PROTECTED] wrote:
Just one tip maybe would be better to dereference PMethod after assigned
check in the Callback proc
Ok, didn´t think about it.
Reattaching the patch, which this fixed. Now I tested with both
Vincent Snijders wrote:
Felipe Monteiro de Carvalho schreef:
On 3/13/07, Luiz Americo Pereira Camara [EMAIL PROTECTED] wrote:
Just one tip maybe would be better to dereference PMethod after
assigned
check in the Callback proc
Ok, didn´t think about it.
Reattaching the patch, which this
On 3/14/07, Vincent Snijders [EMAIL PROTECTED] wrote:
Maybe it your are using fpc 2.0's windows unit.
Yes, I am using 2.0.4
--
Felipe Monteiro de Carvalho
_
To unsubscribe: mail [EMAIL PROTECTED] with
On 3/14/07, Vincent Snijders [EMAIL PROTECTED] wrote:
IMHO Self.SetWindowLong is not so nice looking, SetWindowLong looks better.
Ummm ... I don´t agree. There is also Windows.SetWindowLong. By
specifying where the function comes from, I avoid having to think
about which of the 2 the compiler
Hi,
yesterday I was discussing with Felipe about the AllocateHWnd function.
Since we disagree a little about some things I'd like to ask others
about their understanding. Here is a small piece of code:
TLCLWndMethod = *procedure*(var TheMessage: TLMessage) *of Object*;
*function*
On 3/13/07, Christian Budde [EMAIL PROTECTED] wrote:
Btw. this is also a test if I am able again to send a mail to the
mailing-list. I hope it works :-/
Yes, it works =)
Today I was for 2 hours looking at why the program crashed. I tryed to
debug, but the result´s were extremely illogic (a
Hello,
It´s almost working. I am quite proud to have created a completely
independent implementation of AllocateHWnd =)
Ok, now my problem is that TMethod has 2 informations. A Code pointer,
and a Data pointer, and I can´t seam to find enougth space on
SetWindowLong for 2 extra informations.
Felipe Monteiro de Carvalho schreef:
Hello,
It´s almost working. I am quite proud to have created a completely
independent implementation of AllocateHWnd =)
Ok, now my problem is that TMethod has 2 informations. A Code pointer,
and a Data pointer, and I can´t seam to find enougth space on
When you have a reference to a method (e.g. function of object) the
address operator doesn't return the address of the function, but
instead to a TMethod record which contains two pointers: to the
function and to an object which is the implementor of the
function/method (Self).
Regards,
Flávio
Hi,
I decided to follow vincents idea and allocated memory on the head using GetMem.
I did a simple test, and it seams to be working perfectly =) I was
able to send and receive events using AllocateHWnd.
One thing I noted is that on Delphi, the WndProc will normally have a
call to
Forgot to attach the patch =)
--
Felipe Monteiro de Carvalho
allocatehwnd.patch
Description: Binary data
Felipe Monteiro de Carvalho schreef:
Hi,
I decided to follow vincents idea and allocated memory on the head using
GetMem.
On the heap :-)
I did a simple test, and it seams to be working perfectly =) I was
able to send and receive events using AllocateHWnd.
One thing I noted is that on
Felipe Monteiro de Carvalho wrote:
Forgot to attach the patch =)
Just one tip maybe would be better to dereference PMethod after assigned
check in the Callback proc
Method := PMethod^; //- if PMethod is nil there would be problems
if Assigned(PMethod) then
Method(Msg)
as alternative
Vincent Snijders wrote:
One thing I noted is that on Delphi, the WndProc will normally have a
call to DefWindowProc, and this is obviously Windows only. So, to keep
compatibility with Delphi, every WndProc used with AllocateHWnd would
need to have a IFDEF Windows, with a call to DefWindowProc
Luiz Americo Pereira Camara wrote:
Felipe Monteiro de Carvalho wrote:
Forgot to attach the patch =)
Just one tip maybe would be better to dereference PMethod after
assigned check in the Callback proc
Method := PMethod^; //- if PMethod is nil there would be problems
if Assigned(PMethod)
On 3/13/07, Vincent Snijders [EMAIL PROTECTED] wrote:
I think you should use SetWindowLongPtr to be win64 safe.
I am using Widgetset.SetWindowLong, which should be win64 safe (ok, I
wasn´t using it all the time on previous patch, next one should fix
it). SetWindowLongPtr doesn´t seam to work
On 3/13/07, Luiz Americo Pereira Camara [EMAIL PROTECTED] wrote:
Just one tip maybe would be better to dereference PMethod after assigned
check in the Callback proc
Ok, didn´t think about it.
Reattaching the patch, which this fixed. Now I tested with both nil
and non-nil methods.
--
Felipe
On 3/13/07, Luiz Americo Pereira Camara [EMAIL PROTECTED] wrote:
Why? I think you have called DefWindowProc already in
CallbackAllocateHWnd.
No, he is calling DefWindowProc only when Pmethod is not assigned
Another idea here is to always call DefWindowProc. So you have to add
a IFDEF only
59 matches
Mail list logo
