Closed GoogleCodeExporter closed 9 years ago
New Patch to for the Wrap*.pas
Now it can be compiled but still access violations on this poor example:
MyForm = CreateComponent('TForm', None)
or
MyForm = Form(Application)
or am i doing something wrong?
Original comment by eneg...@googlemail.com
on 4 May 2009 at 4:17
Attachments:
[deleted comment]
I'd also be interested in getting it work (again?) for Lazarus. I made
independently
that little patch in attachment. Mainly setting ..DELPH7_OR_HIGHER, instead of
those
many many $IFDEF FPC's, but that may be to much? Visual Components in Laz IDE
were
not stable - see below, how is yours?
A main concern for me however as of now is usability of VarPyth.
Callback/Wrapping
perhaps latter.
Here the problem description from a mail I wrote to the P4D-list:
------------
I tried to use current http://code.google.com/p/python4delphi with Lazarus. Did
somebody use P4D successfully with recent Lazarus? Patches? I face a few
problems.
My aim is to test/use Lazarus+Python as efficient platform independent and free
dev
environment. As an alternative to the fat and baggy wxPython GUI system. Laz,
with
very small EXE footprint size and better RAD and tough speed - but just for
rather
naked GUI wiring (and few speedy loops - alt: Cython), while doing the actual
app,
data, algo, object, file, interface ... work and all, in Python. Python can
also use
reversely use Delphi objects/funcs quite simply. Laz claims to be mature, and
the
first impression is good, just re-compilation a little slower than Delphi.
With Delphi I used this P4D method once in a smaller app some time ago -
initially
only wanting to re-use some Python modules and then found me shifting more and
more
all the data/algo work to Python. I felt a ">3x" coding speed up and much better
readability, object orientation, overview, interfaces, flexibility,
dynamics/introspection, debugging, testing etc. While GUI wiring was a lot
tighter in
D, than wx/wxGlade etc.
P4D worked principally with Lazarus, but only after a few a adaptations. Mainly
setting DELPHI_4..7_OR_HIGHER. see the little patch in attachment. Is nobody
using?
(After re-building Lazarus IDE for Visual Python Components it Crashes on usage
of
non-crucial TPythonGUIInputOutput, and the rebuilt Laz IDE here becomes at all
somewhat instable!? But I stepped back and use the P4D-units/objects just
manually,
anyway only a few things to set up and wire...)
Yet when using the crucial VarPyth unit, upon basic things like pymod :=
VarPyth.Import('pymod') => EVariantError "Method
TCustomVariantType.VarDataClear not yet supported"
VarPyth variants would allow to walk seamlessly and comfortably into the Python
object tree with the '.' operator like pymod.myobj.myattr.x(7).y := z; ...
And without that option, much of the P4D charm disappears.
In VarPyth.pas there are many $IFDEF FPC's , but it doesn't seem to work at all
so far!?.
What about this problem, and what could be a workaround?
### from variants.pp #########
procedure TCustomVariantType.VarDataClear(var Dest: TVarData);
begin
NotSupported('TCustomVariantType.VarDataClear');
end;
...
#########################
Original comment by kxrobe...@googlemail.com
on 30 May 2009 at 10:25
Attachments:
Does any Lazarus user want to become a project member and apply the patches?
Original comment by pyscripter
on 6 Dec 2009 at 12:21
Partial compatibility is now restored. Pls see the relevant Wiki page.
Original comment by pyscripter
on 16 Dec 2009 at 10:01
Fixed in version control. All parts of P4D now work with FPC
Original comment by pyscripter
on 10 Dec 2011 at 5:11
Original issue reported on code.google.com by
eneg...@googlemail.com
on 4 May 2009 at 12:41Attachments: