I decided to have a concerted effort to get the excellent DWScript (Delph Web Script DWS) integrated into a simple IDE using SynEdit. DWScript is currently being agressively developed and has a number of advantages over other Pascal Script libraries, however it does not contain an editor or any IDE example beyond a simple memo control to prove execution capability. It does contain a number of hooks for editor / debugger integration and in fact when DWS was reawakened a while ago, releases did contain an example of a SynEdit / DWS2 (as it was then) integration. An example can be found in the file dws2src20-20030907.zip in the \dws2rel\dwstools\idedialog\source where there is a 'mini-IDE' with editor window, call stack, breakpoint window etc. Really nice. I did get this working some months ago using an old SynEdit and the DWS2 that was included in this file.
So, I have now tried achieve this (or a similar) ide using the latest SynEdit (downloaded from SVN) and the latest DWScript (also from the SVN). Both libraries are installed fine into XE and their demos run fine. I then tried taking the ide example from the old "\dws2rel\dwstools\idedialog\source" and updating the code but much has changed. Frustratingly, not so much has changed that I gave up quickly - I tried searching for the various 'old' type definitions in old source and matching them up with 'new' definitions. Finally though, after several hours mired in code I decided that someone, somewhere must surely have been down this route?
Has anyone got an example of a DWScript - SynEdit integration using recent DWScript code please? I'm very happy with something simple that I can learn / build upon.
Thanks
SynEdit component has received little maintenance, and even some projects as Inno Setup have changed to Scintilla, Inno Setup is not using DWS but the code can serve you as a basis for new IDE
Dws have a editor on the demos with debuger and remote debuger just download all versions of dws one
Related
I am a C# developer by trade, but have been tasked with making some changes to a Delphi desktop application. I have never used Delphi and I'm trying to identify the version of Delphi the application has been compiled with, and find a (preferably free) development stack/environment.
Looking at the source, there are a bunch of .DCU, .DPP, .DFM, and .PAS files.
There's a .DPR file that would seem to reference all of the forms.
In the .CFG file I found reference to
c:\program files (x86)\borland\delphi7\Projects\Bpl
Based on the above info, what tools should I use to design and compile this application?
That entry in the .cfg file is a clear cut indication that the project was most recently built with Delphi 7.
However, it may be more tricky to build this project than just to install Delphi 7 and press build. You may very well need to install a bunch of third party packages and libraries. In an ideal world there would be documentation on how to build, or at the very least, how to create a build environment. Sadly, you may not be living in an ideal world!
I'm trying to .... find a (preferably free) development stack/environment.
Well, Delphi 7 is not free. There are free Delphi like development environments, most specifically Lazarus. However, you would need to port the existing code, which is likely to be a non-trivial task. Especially if you have no Delphi experience.
It appears to be Delphi 7.
But the compiler version is only part of your problem, as several commentators have mentioned here. Unless they used only Delphi components, you're going to need to find the component libraries that were used, and that could be nearly impossible in itself. If it used any DLLs or BPLs, you'll need to find them as well, and possibly re-build the interfaces.
I'd spend some time trying to track down a backup that was made of the system that this software was developed on, as that's your best bet. It won't cost you anything assuming everything is still intact.
But trying to load up the source into D7, or anything for that matter, is going to be a total crap shoot unless you know all of the libraries that were used, how things were configured, all that good stuff.
It would be far more efficient for your company to just hire a Delphi expert for a day or so to dig into this for you than for you to waste a week or two of your time on something you don't know anything about.
I've just downloaded from SVN the DUnit2 code base.
Does someone has compiled it successfully?
What steps/prerequisites I've to follow in order to compile it?
Do someone knows if an already compiled version exists?
thank you
fabio vitale
In the projects directory, find the subdirectory corresponding to your version of Delphi. In it, you should find a project-group file, either DUnit2ProjectGroup.bpg , DUnit2ProjectGroup.bdsgroup or DUnit2Delphi<version>.groupproj. Open it and compile all the projects in order.
Using DUnit2 is pretty much the same as using DUnit.
In case someone else stumbles over this question while trying to make DUnit2 run on Delphi XE (or XE5):
TL;DR:
Dunit2 (official SourceForge source, revision 101) doesn't currently (being as of this writing on 2015-06-01) build successfully on either Delphi XE or XE5.
To make it build on XE or XE5, go get the patch I posted here
Apply it to the source tree. It should now compile and you should be able to open the .groupproj and build all the contained projects successfully.
The patch may be applied with and was created with TortoiseSVN (in case it matters).
Longer version:
Amazingly tonight (2015-06-01) I followed the same steps as Fabio (in 2012 no less) and ran into exactly the same issue (E2010 Incompatible types: 'Pointer' and 'Integer') trying to compile DUnit2 (revision 101 trunk checked out directly from SourceForge) on XE and XE5.
I've come to the following conclusions:
1) There's multiple issues with the head revision with respect to both XE and XE5.
2) The key issue above that Fabio mentions can be fixed by replacing IntPtr with Pointer.
This doesn't actually seem to make any difference in the code as far as I can tell, and the test suites also pass fine on both XE and XE5 after this change, though caveat emptor - I've not looked too carefully either (and also subject to caveats below.)
3) Project search paths being out of date [XE]. Just needed updating/fixing.
4) Missing $DEFINES for XE5 and others, despite some other code being quite aware of XE5
5) Some enhanced TRect stuff that's not available on XE. (The amount is relatively small and relatively trivial to inline to more basic expressions that will compile and is available on XE so was by no means show stopping.)
(Re 3,4 & 5 -- Sadly I get the impression the codebase isn't very well tested against multiple compiler/BDS targets.)
6) Some kind of Application.OnIdle/GUI testing bug (run T_TGUITestCase tests to see it) whereby the GUI automation tests would block unless you keep "feeding" the Windows Message queue by say moving your mouse or pressing the shift key to trigger Application.OnIdle events (repeatable on my Windows 8 XE5 and XE binaries).
Now speaking off the top of my head, and from vague memory from many years ago, I seem to remember having run into this before, and that it is down to a subtle change in behaviour either in Delphi or in Windows some time ago. -- IIRC in past, it used to be the case that one would would actually still get the occasional Application.OnIdle() call in your Delphi app even when nothing else much was going on on the system, even when you set Done to True. And as I recall, this changed at some point due to either a change in Windows or Delphi (can't remember which) several years ago and one had to be a bit more circumspect about setting Done to False if you didn't want your App to go to sleep entirely. In any case, it clearly was/is an issue on my PC tonight with the current (as of this writing) DUnit code, so I had to patch around it.
I did this in arguably a rather kludgy way, e.g. by manhandling things via providing an OnIdle handler while running GUI automation tests to signal that that the app is not in fact done (e.g. "don't block, don't go to sleep") and then reinstating any prior handler immediately after. There is no doubt a more elegant solution to this, perhaps by posting a message to ourselves to keep the app "alive", but my first attempt or 2 at something better didn't work out and I'm not interested enough to pursue this further. I'd be interested to hear of a better fix though.
I've supplied patches, but got no feedback from the DUnit2 team on SourceForge. So I forked DUnit2 with the full commit history into my Github account. I've applied many fixes there, including the compilation issues with XE & XE3+ and the scriptable self-tests that pause if no mouse action occurs. I'll continue my development of DUnit2 on my Github account [https://github.com/graemeg/dunit2].
as the title says, I'm trying to compile a Win32 program without the aid of an IDE, just so I can learn. I'm using Borland Studio 2006, and my first thought was to take some files generated from a Forms application from the IDE and compile the project file... that gave me errors about expecting unit and finding object instead. I know that's from the dfm file which holds all the settings for a form, but I don't get how the IDE deals with that file, can anyone help me understand the system better? :)
If I have understood correctly, you need to grasp the structure of a Delphi project and how Forms and units work together. You cannot just cherry-pick some files and expect to be able to feed them to the compiler.
You also have to set the path to the library/components/used files so that the compiler can find everything it needs, starting with the project dpr.
I would recommend that you try first to run your project from the IDE, then once it runs, you can try it from the command line.
I found out all I needed to do is compile the top level unit into a dcu, and then the project will compile :) If anyone else is trying to do the same thing, there's some great info at the bottom of this page
http://www.codexterity.com/raw-delphi/index.htm
WANT automates the process of building, testing, and packaging applications and libraries much like Jakarta Ant does
You wrote in question that you are using BDS 2006. If you want to learn more recent build process in Delphi I suggest you to upgrade at least to Delphi 2007 which introduced MS Build usage.
Of course MS Build acts like "wrapper" so this is not must have but nice have :-)
I havent used synEdit for a while, but today I found that I needed a good editor for a form with script support. As I went to download synEdit (which my mind had frozen in time as a "sure thing") I found that the original author had abandoned it. I am aware that FreePascal has a synEdit version - and I hear there is a more recent unicode version out there "somewhere"-- but where exactly can I get the newest and best version?
I would prefer unicode support if it's possible, but more importantly is support for dynamic styling (being able to add tokens to underline keywords, a bit like Delphi does when you access a variable of a class you just typed).
http://synedit.sourceforge.net has a link to the Unicode version.
SynEdit is much faster than any other text editor component. See the comparison benchmark here.
Currently I'm developing a new IDE for Arduino (official one is lack too much standard IDE features) to contribute to Arduino community. Since I want my IDE to run natively without rely on any VM and cross-platform is not my goal, so I took my o'good friend Delphi 7 and search for updated SynEdit VCL. Slightly dissapointing is it still has no very important feature: code folding (which you can say as "standard code editor feature" nowdays).
But after a little search I've found a descendant project which based on SynEdit which feature code folding: Mystix (hosted at SourceForge). You can simply overwrite your previous SynEdit source with this one (there is no new dpk package to install). It's based on SynEdit 2.0.1 anyway.
Documentation is a little vague (you have to throughfully examine the source code to get idea how to use it properly), but here is hint how to use the code folding feature:
SynEdit1.CodeFolding.FolderBarColor: = clDefault;
SynEdit1.CodeFolding.HighlighterFoldRegions: = False;
SynEdit1.CodeFolding.FoldRegions.Add(rtChar, False, False, True, '{', '}');
SynEdit1.CodeFolding.FoldRegions.Add(rtKeyword, False, False, True, '/*', '*/');
// and don't forget to initialize...
SynEdit1.InitCodeFolding;
// ... and enable it
SynEdit1.CodeFolding.Enabled: = True;
Mystix is released under same license as SynEdit (MPL).
I strongly recommend the use of Scintilla. It has all features you are looking for. It is much more capable and mature than SynEdit. The development of SynEdit decreased in the last yeast to almost standstill. The only problem of Scintilla is that the no one is updating the Delphi code that binds to it. The SourceForge project is not active anymore. You can find Delphi code in the following URLs:
Borland Delphi control wrapper for Scintilla and Delphi Components
The latter contains the most recent code. It is not difficult to update it to add recent features of Scintilla.
I would not use the link in the current answer as it hasn't been updated lately even though it is still getting about 80 downloads a week on SourceForge. (https://sourceforge.net/projects/synedit/)
There are three fairly recently updated versions on GitHub:
The generally considered "official" version:
https://github.com/SynEdit/SynEdit
A fork with new features added and a bunch of cruft removed
https://github.com/pyscripter/SynEdit-2
Embarcadero's "official" version, supported by GetIt. (Their "TurboPack" packages removed support for old Delphi versions to nudge people to the latest version.)
https://github.com/TurboPack/SynEdit
For a brief history see this thread on DelphiPraxis:
https://en.delphipraxis.net/topic/3028-synedit-preferred-version/?do=findComment&comment=24291
We recently converted our long-running Delphi project to Open Source. Multiple people have contributed patches already, which is great, but unfortunately forms and frames when saved with Delphi 2006 (and later) contain new properties in the .dfm that are not handled by older versions. Forms are handled quite gracefully by the IDE ("ignore propery?"), but frames are loaded at runtime and result in errors. Not an option, as far as I'm concerned.
I now removed those properties from the .dmf files by hand, but I am really wondering if there is a more elegant solution. There is no way to save in a backwards compatible format from the new IDE's, is there? Are there existing tools to strip the nonsupported properties from the .dfm's ? Any other elegant solution I am missing?
Normally, with a commercial project, I'd just upgrade the project to the most recent version applicable... but as this is open source I really don't want to loose out on those developers still working on Delphi 7. That includes myself, actually.
The JEDI JVCL project uses a little utility dc.exe (delphi cleaner) and a list of properties in DFMs that are not present in older versions of delphi, mine contains the following text:
*.PopupMode
*.PopupParent
*.ExplicitLeft
*.ExplicitTop
*.ExplicitWidth
*.ExplicitHeight
*.BevelKind
*.BufferDocument
*.DoubleBuffered
*.ParentDoubleBuffered
*.DisableHyperlinks
*.AlwaysEnquoteFloats
*.PixelsPerInch
I run this dc.exe utility from a batch file which cleans my dfms before I commit
changes to subversion. The syntax in my batch file for this is:
dc.exe -s -fd10.txt *.dfm -i
You can grab my stuff at:
http://sites.google.com/site/warrenpostma/files
You can try Andy's DFMCheck. It can automatically open and close all forms and frames in a project, which makes the IDE remove unknown properties (as Marco wrote).
Well, for sake of completeness:
Open the dfms in the oldest Delphi supported, let it remove all unknown properties, change a property and save.
For your purposes, Warren's solution is better, but it can be a workaround. I did it for a while when we were dual D7-D2006ing.