Delphi To C#
I find I am at a crossroads. I have over 20 years of Delphi development experience. Despite Embarcadero’s best effort, Delphi is slipping as far as popularity and to stay in the game I need to diversify. I have been looking at C#. It certainly has a number of things going for it. So I have started moving from Delphi to C#. Learning a new language can be a bit daunting though when you have been stuck to one for so long. But persistence and determination will pay off.
Been exploring for a couple of months and like what I see:
- C# is object oriented.
- C# has all of the reflection and run time type information and more that Delphi has.
- Data binding in C# is far superior and easier to use, although I am still back with Delphi XE4 with that. There is no having to create special adapters and treat them like a dataset.
- The philosophy behind C# appears in some ways familiar to a Delphi programmer (not surprising give the history behind it). For example the way the interfaces are declared and implemented in classes.
- C# has drag and drop UI design capabilities that are not a lot unlike that of Delphi.
- The community edition of visual studio only a download away it. This is very attractive for a single professional developer.
- Very large on line community presence of C# and .net .
- Extensive documentation at least on line.
- The availability of the Mono project for development of Linux and Mac OSX applications.
- Along with Mono is the availability of Xamarin for mobile applications.
- There is a significant amount of third party and open source libraries and frameworks.
- The ability to implement design patterns are well supported.
The more I play with C# the more comfortable I am with. I’ll talk a bit more of my learning and transition from Delphi to C# as time goes on in the hope someone may find it helpful and interesting.
Posted in C#
Tagged with: C#
I have begun using Report Builder, converting from Crystal Reports. Over the years, I have felt the support from Crystal Reports for Delphi developers as fallen by the wayside. I began looking for an alternative. Report Builder while is some ways being very different is in may ways similar, only far more flexible. With the product being written in Delphi makes it 100% better to integrate into a Delphi application, without a messy run-time.
In order to have separate report files I needed to create my own report designer program using the Report Builder report designer component, but it means I have one that suits the application and even takes care of some items that are the same from report to report automatically. I also needed to initially create some infrastructure for a universal data access method via Remobjects Dataabstract, but now it is place and works perfectly. I design a single SQL query for each report in most cases which tends to work a little faster than the using report master-details and sub-reports. However if I want to use sub-reports with master-details I can. With the professional edition giving the RAP language (Report Application Pascal), it gives me the ability to code complex calculations in the language I know. Performance in most case appears to be better than Crystal reports. I think I have a good solution.
Initially, since I purchased the server edition I created a Report Builder Server. I found though that it’s performance was not that great. I saw a report builder demo application in the remobjects sdk samples folder, I tried and was blown away by the difference. I have now implemented that instead and it makes a world of difference. The only issue is that by using a remobjects sdk service to execute the report and then send the results to the server, a delay is more likely to be experience by the user with a larger report with no feed back. However for reports that are only a few pages, the report comes back so quick. So if you intend use Report Builder and prefer the reports be built on the server for a client-server reporting solution, doing it in a remote service using remobjects is a better way to do it than using the Report Builder Server product by far. I now have a good Delphi report solution that with the help of remobjects dataabastract is also pretty close to being database gnostic.
A couple of days ago I talked about the issue of individual users needing to be able to backdating the “system” date when raising transactions for example at the beginning of the month to finalise the end of the previous month in an accounting system. Click here to read this post if you missed that. Well I have installed it at the client site today. There is always something missed. Like I had forgotten to exclude dfm files (and I use text dfm’s) for example. We ad tested the the main parts of the program but failed to test some (my face is red). But at this point we appear to working again.
Today I have started using RemobObjects DataAbstract after looking at it over the last six months. Its not a bad product. Today I am writing a little utility that has to work with Paradox. I could choose to use the old tried and true method of using TTables directly. But with not a lot of more work I will have have a database gnostic version that could later be easily pulled a part and made a part of my main application for this customer which I am converting to partly use a remobjects middle tier.
Remobjects DataAbstract is built on top of their RemobObjects SDK product and SDK is included in the DA box. It allows you to create a local server, meaning you can create an application with N tier logic but not have separate exes. This is good for small or what might be at first only single user applications that can easily be split up into separate ties later on. It has taken me some time to get a grip of the product and documentation is not brilliant. They tend to rely on the newsgroups for support, but with me being in a different timezones, I usually have to wait for the next day to get any answers to problems I have. However so far I like the product.
I have a client for whom I look after with a customised account package had me move there system to a terminal server. Everything works great. I had minor issues like printer setups i.e. Crystal reports doesn’t print courier new font properly to a printer that is redirected from the client computer. These were a nuisance but not that hard to fix.
We wanted the operators to only access this package on the terminal services and nothing else. This I achieve via an icon that automatically logged them in. The user settings on Terminal Server automatically started the software and all is good.
Except that this doesn’t provide the window task bar and only administrators can change the system date – with good reason obviously. This provides a problem for a couple of the book keepers that from time to time back-dated their computers to finalise the previous months books for the company. They can no longer do this. So how could a provide them the ability to enter transactions into the account system as if they were doing them of a particular date different to the current system date without affecting the orders, quotes, invoices and purchase orders that other departments needed to do.
My solution was to store a “date difference” for each client via a client specific configuration file or in the registry. A panel that shows the date displays on the main screen. A double click event handle on that Delphi form brings up a “date picker dialog”. The date selected is compared to the current system time with the difference between stored in the configuration as the date difference. I created a function and with using GReplace (a multiple file find/replace utility) replace all occurrence of the sysutils.Date call with my new function call. It actually has taken me longer to explain it on this post than actually do it. All I have to do now is put the system through some testing to check all is well and we’re all good. For good measure the panel color is set to red when the date difference is not zero as a reminder to the operator.