Is there a synedit package that works with firemonkey (or someone working on it) ?
From what I can gather there was a VGScene port earlier (see: this site), but it seems to been removed.
Also see this site:
There most likely is not (at the moment):
From the homepage:
It is a pure-VCL/CLX control, meaning it is not a wrapper for Microsoft Windows
controls and so no run-time library is required.
CLX or Component Library for Cross Platform is the cross-platform equivalent of the VCL - Borland's widget library.
From Nakeymonkey - native controls for firemonkey
With the VCL, Borland never had to worry about all of this because they just wrote a wrapper around the Windows API Rich Edit control. So why didn’t Embarcadero do the same thing with Firemonkey? Because Firemonkey also needs to compile for OS X and the Windows API Rich Edit control doesn’t exist there.
Links:
Embarcadero Delphi
Qt.pas pascal bindings for QT
Related
I'm using delphi 2010, and in order to create components i'd like to see the source of delphi components such TEdit, TButton... But the problem is this option is unavailable in my IDE, the type of any added component is written in black (and not in blue so i can see the source). So how can i get this option?
Thanks for your replies.
You seem to be using either a trial version or starter edition of Delphi. The source is deliberately not available. You would have to acquire / pay for a higher edition of Delphi, such as Pro, Enterprise, Ultimate, or Architect.
If you wish to study how components / controls work, find a popular third-party one. For example, I've been experimenting with Chrome Tabs lately.
I have to develop an application to run on Windows CE accessing a remote Firebird database.
I would like to use Delphi to do so.
Is it possible?
Native Delphi only works with x86 compatible processors and Win32/Win64 or MacOS 10 API.
Ken White already pointed to you Delphi Prism, however if you would purchase it, instead of re-marked tool, you'd perhaps purchase the original product, i heard it comes with multiple platforms support instead of one. RemObjects Oxygene is the original product, part of which is re-sold as Prism.
Another option would be using Lazarus (vanilla or CodeTyphon distro). Its LCL library mimics VCL in many respects and FPC compiler mimics Delphi language (and some other Pascal dialects as well).
http://www.pilotlogic.com/codetyphon/help/index.html?cross_build_for_windows_mobile.htm
http://wiki.freepascal.org/Windows_CE_Interface
http://www.lazarus.freepascal.org/index.php?topic=8175.0
No, it isn't. Delphi XE2 does apps for Win32/64, OS X, (and with the help of FreePascal, iOS), but not for CE.
You can probably use Delphi Prism to do so. There is a separate delphi-prism tag for that here at SO.
In fact, you may be able to use the Delphi IDE to build Windows CE applications, using KOL-CE library, after some adaptations.
KOL-CE - Key Objects Library CE is a set of objects to develop powerful (but compact) Windows CE/Pocket PC/Windows Mobile/Win32 GUI applications using Free Pascal Compiler. The library is based on KOL library by Vladimir Kladov (http://kolmck.net).
It targets the Lazarus IDE, but since it is a fork of a Delphi project, you may be able to use it in your Delphi IDE, perhaps after some modifications. And if you are not able (or do not have the time) to do the needed modifications, I'm quite confident that you would be pleased to use the Lazarus IDE and modern object pascal instead of switching to another language.
You need to install the FPC arm-wince cross compiler for Win32 to compile WinCE executables, but you develop your application in Windows, with the IDE.
Note that KOL is a light new set of components, very diverse to the VCL. Very powerful, but only low-level object code can be re-used, since they are not compatible with the VCL (or the Lazarus LVCL).
Using Lazarus and its native LVCL components is also available to Windows CE, is much close to the VCL classes layout, but will produce much bigger executables than KOL-CE.
For the historic perspective: no you can't in Delphi itself as of Delphi 2007.
In Delphi 2005 and Delphi 2006 could do this, targeting the .NET Compact Framework on Windows CE as Delphi contained a Delphi .NET compiler that was more compatible with the Delphi language than the current (but much more evolved) Oxygene .NET/Java platform implementation of the Delphi language.
As of Delphi 2007, the Delphi .NET compiler got retired.
Right now, Oxygene is much better as it supports a broader set of language and platform features than Delphi .NET ever did. It is less compatible with the Delphi language because the platforms it supports warranted for some language deviations that in practice are very useful.
Oxygene ships both separately (with a full feature set) and as Delphi Prism (with only the .NET portion).
For Delphi 2005/2006 you needed the CF Build Helper from Jeremy North and the Class Helpers I wrote (they are included in the CF Build Helper). A nice article on how to use both is at EDN.
Given the hoopla you had to go through back then, it is much wiser to use Oxygene if you want a language very close to the Delphi language.
For a historic overview of Pascal and Delphi like languages, read this article by Jim McKeeth.
I think pbear's component HTML Components, v 9.45, is just what I need. His free download only has packages for Delphi 2006 and earlier. I have Delphi XE. How would I install his components into my Delphi?
Try this Google code download site THtmlViewer.
Seems to be updated to XE2 version plus Lazarus.
See also this answer to SO question How to display an email images on Pbear Html viewer component?.
Have you considered using Delphi Chromium Embedded? This is the Delphi API for Google's Chromium, which is used by the Google Chrome web browser. Several Delphi versions are supported, including XE and XE2.
Unless you only need rudimentary browser support, it makes sense to use an up-to-date browser with solid support for modern web standards.
The repository includes Delphi sample projects for VCL and FireMonkey.
Looking at the new Delphi XE2 with Firemonkey. Considering that it compiles for Windows, Mac OSX and iOS, VCL components are useless in a FireMonkey application.
My question is: Is there/will there be an Indy Firemonkey Edition? Cause I seriously need the IdHTTP.Post();. If not, is there a way to do this in FireMonkey?
I have been googling for quite awhile now, not finding anything. :S
VCL means Visual Component Library. There's nothing about Indy that is "visual" (meaning "seen at runtime"), meaning that "VCL components are useless in a FireMonkey application" has no relevance to Indy.
You can create a new FireMonkey HD application in Delphi XE2, target OS X, and the Indy component pages are still available in the IDE, meaning that they are compatible with supported FireMonkey cross-platform targets. They're also available for FireMonkey HD Windows targets (32 and 64 bit).
Indy ships with the IDE (and has since D6) so there is nothing extra to buy if you already have XE2 installed. Also, Indy is open-source, so you can upgrade an Indy installation using source code from Indy's public access SVN server or mirror.
Regarding FireMonkey, Indy does work in FireMonkey. Indy uses whatever the native socket API is on a given platform (WinSock on Windows, Posix on Mac, libc on Kylix, etc).
The only known gotcha with Indy under FireMonkey at the moment is the TIdAntiFreeze component is not available at design-time. The IDE cannot resolve it correctly due to the non-standard way it is packaged (to be adressed in Indy 11). You can instantiate it programmably in code at run-time, though.
I made a client server example using tcp indy http://www.freelancecode.net/community/viewtopic.php?f=35&t=246
The Components Not Used in iOS Apps DocWiki page for Delphi XE2 lists most of the Indy classes:
The following list is the set of components (along with the used
units) that might be available in the Tool Palette for iOS
applications, but are not supported for iOS applications.
First of all (before this question get down voted): I am a developer developing 99,99% of my programs using Delphi targeting Win32 (developing in Delphi 7 still, very slowly migrating to Delphi 2010).
When Delphi 2006 or 2007 (can't remember which version at the moment) came out I bought the RAD Studio edition to be able to start developing .net applications using Delphi.net and VCL.net.
I played around with it for some short time, but in the end, due to work load just kept using Delphi 7 as development platform.
When Delphi 2010 came was released, I decided to give .net a go once more, and (foolishly) bought the Studio License once more thinking the include PRISM was the previous Delphi.net (to be developed in the Delphi IDE).
Now that I have installed PRISM (and the Visual Studio 8 IDE - o horror), I am just wondering whether PRISM is a new version of Delphi.Net or not (probably not). And if I can use some of my Win32 code under Prism.
UPDATE AFTER SOME REPLIES: I keep the question open because you get more answers when a answer has not been selected yet.
I do miss the Delphi IDE though. It's all a mather of taste but having to develop in two different IDE's (where f.i. the keyboard shortcuts are different - and I don't want to give up the Delphi ones, thank you)) is not my idea of spending my development time.
Prism is a replacement for Delphi .Net - it has been developed by RemObjects and its original names were Oxygene and Chrome ( http://www.remobjects.com/ ).
Because it's much more mature than Delphi .Net in the .Net segment it now is included in Delphi RAD Studio instead of Delphi .Net.
You won't be able to use all of your W32 code, but the syntax is very similar and most algorithms will probably work without any change.
See http://prismwiki.codegear.com/en/Win32_Delphi_vs._Delphi_Prism for a detailed comparison of Delphi W32 and Delphi Prism.
No. Delphi.NET was designed specifically to be backwards-compatible with Win32 Delphi code. Prism is not. It was not developed by the Borland/CodeGear team, doesn't include VCL support, and has a handful of minor language differences. It's better to think of it as a new dialect of Object Pascal than as Delphi.NET.
The main difference was that Delphi.Net was mainly a port of the RTL/VCL to .Net, as well as an adaptation of Object Pascal to be a .Net language.
It had to include a full blown IDE with a special Delphi.Net Form Designer.
The goal was to help move a VCL Forms application to .Net with a minimum of changes, or create new application without having to re-learn the IDE and the library.
Delphi Prism is also an adaptation of Object Pascal to the .Net world but with more emphasis on being a fully fledged .Net language (even more so than C#) and much less worries on being compatible with Delphi.
It is just the language, hosted in Visual Studio, and does use whatever designer is provided by the IDE.
So in the end pure Pascal code will be very much similar, and easily ported, but rich GUI applications will need more rewriting/redesigning.
Yes and no.
Oxygene (FKA Delphi Prism) replaces Delphi for .NET, but it is not a new version of it.
They have different design philosophies and are not 100% compatible. As Francois pointed out, Prism does not include the VCL.Net. Instead it focuses completely on supporting the .NET GUI Frameworks: WPF, Silverlight, Prism, WinForms, ASP.NET, etc.
Delphi for .NET was all about migrating and backwards compatibility. Delphi Prism is all about being a full featured .NET development language and "forward compatibility."
You can create you pure business logic as code compatible between Delphi native and Delphi Prism, but all the GUI and IO code (anything that makes use of the VCL or RTL) will be specialized.
Check out the Oxidizer and ShineOn for more help in migrating and code compatibility with Delphi Prism.
No, Prism has been labeled Delphi more to make it more popular, like Delphi PHP.
It's not like Delphi.NET, with a VCL-alike etc, or even a compatible language (it uses method instead of procedure and many other deviations).
So you can see if you like it, but from what I have seen from it, having used Delphi won't be much of an help, and neither do existing codebases.