Monday, February 24, 2020

Live Youtube, Chat, FDK & MVVM...

Since 2017 I have this topic on my todo list:

- Create Youtube Video's

After my FDK was ready for release, I wrote some kind of little documentation and some demos, but everything was a little too "short".

The other Idea was to convince people to buy my Framework. While the first customer was waiting for the version, I had to develop my fancy setup/update/shop installer. And also the local service-desktop-software to handle the versions, upload, download and payment. Too bad, at this time my MVVM-Framework (version 2 or 3) was not as good as my "final" version today.

So much to do, but no time for videos. Last time I uploaded a video to my channel is 6 years ago...

Now as my MVVM-Framework is working,  I'm able to refactor my Service-App. I also had to improve the invoice print. The first time I'm using the PDF stuff from my friends at Gnostice.

While talking to Craig Chapman he asks me why I don't do live streams... Never tried, beside one round table with Jim McKeeth. 

A live session only makes sense to me, if this is announced in advance. If nobody is watching  - especially on my channel with only 35 subscribers (at the moment) - this is no fun. Users must also be able to chat with me... My Chat-Software with WebSockets is not ready at the moment, so I installed a free Website-Chat-Script from on my homepage.

Perhaps I'll start with some normal tutorial videos for FMX my FDK and my new MVVM-Framework. Then pre-recorded tutorials with a Q&A session like the webinars.

In any case - please subscribe to my channel and hit the bell icon for notifications. If I'll get enough subscribers, I'll try to do the "live-thing" and we could also have friends like Craig or Olaf joining it.

Wouldn't it be great to have a monthly round table?

Please leave a comment! 

PS.: I have a TeamSpeak-Server running for this kind of round table since 06.10.2011. Only used this once for Delphi-Talks...

Wednesday, February 12, 2020

Delphi 25th birthday.

Once Upon a Time...

A young developer programming every day with this Z-80 book on his knees. Z80-ASM was a third language he'd learned. First was a ELAN on the EUMEL OS and of course Basic. By selling his first Basic program to a local computer dealer ( a Paint like program ) - he was able to buy his first color monitor and a floppy disk drive. His first ASM program was FL-DOS-800 a Disk Operating System to load, read, write erase files on a floppy disk and also a Hex/ASCII Disk Editor. Using only 1000 bytes of memory it fits perfectly below the build-in ROM of the MZ-800 and boots in just 1 second.

Side note: You can see even in the year 1986 he loved three-letter names for applications and F has to be the first letter... ;-)

With the money from his FL-DOS-800 he bought his first double floppy drive (2400,- DM ~ 1100,-USD these days) 

With this double floppy drive, he could run CP/M and also his first version Turbo Pascal on his MZ-800. Greetings to Anders Hejlsberg who licensed his "PolyPascal" compiler core to Borland.

While working on exhibitions for a computer company, he got to know the first two customers. He got his job and had to create his first business application. But MS-DOS and MS-DOS-Computer where the sales point, so he had to convert his app from CP/M to MS-DOS. Not knowing anything about this "new" OS. At that time he met "the other" developer at school, who was able to help with the core methods. So it was a good idea to build a company together...

Guess what... These two are still working together and nearly everything they've owned depends on this application, started with Turbo Pascal for CP/M on a 64 KB - Z80 Computer.

In those days everybody was using MS-DOS 3.0 which was able to handle only 30MB drives so if you could afford a 40MB ( not GB, TB ) hard disk. you had two partitions. First guess - this disk space will be enough forever... LOL. And of course only black/white, green or amber with the Hercules Graphics Card.

The Application was still growing and converted from Turbo-Pascal 1 to 2 to 3. Thanks to Borland, Version 4 could handle overlay units, so no problems with memory anymore. (640KB ~ 350KB free). With one of the next Turbo Pascal Versions we could do some tweaking and could compile to protected mode - giving us full use of 16 MB RAM. (Not GB) 

After some tests with Borland-Pascal for Windows 3.1. "No, thanks" we'll stay on DOS. Delphi and Windows 95 arrived... A complete rewrite to windows was out of scope in those days and a CRT emulation of the DOS-Screen was just a proof of concept, too slow for the real world. However we were able to show this Version to our customers, and our competitors had a heart attack. (First time)

Windows 95 where the break trough and we had some time to rewrite "stuff". Not everything at this time, but enough to show the first Windows version of our software - compiled with Delphi 3.0.

This was the second time our competitors had a heart attack. We were years ahead and also the first company in our market segment with a windows version. Everybody else was still on DOS.

We had many clients at that time, not willing to switch to Windows. So we had to compile our DOS Version from the same code base with Turbo Pascal 7.

We kept our DOS Software for many years and also converted the DOS-parts, which used direct memory access to the screen, to a Delphi Console Application. Still being able to compile to "DOS" and Windows from the same codebase. This continued up to Delphi 2007.

It took some time, but with our Windows Version, we got the market lead. 

At every Borland/Inprise/Codegear show, I ask David-I or Mathias Eißing (and it became a running gag over time) could we please have a compiler for the Compact Framework, because we want to support Pocket PC's like the iPAQ and in a good manner, the answer was always "we're thinking about this". This was our first and last escape to C# (sorry about that) but we are still able to use the data collected on these devices in our main app. This was the third heart attack - because nobody had support for these kinds of devices those days. (please, last customer buy a smartphone)

You may imagine I could not wait to get started with the mobile development on XE2, to support iPhones. (Bad idea to jump on this train so early) - I was able to compile my first Version of this app and with XE3 you also could use it. ;-)

After so many years of development, doing FMX was a steep learning curve and ARC was a pain in my a**. I think every FMX developer could not wait for 10.4 to develop FMX without ARC.

In 2012 we presented the first version of our app to our customers.

As the first and only App in our market, this remains a heart attack for our competitors and a persistent headache.

With XE4 we could also present our app on Android. It took a little bit more time to solve every problem, however since XE6 everything works fine. 

The App has grown (255.000 LOC) and got a new design (same on every platform).

Of course this depends 100% on my Firemonkey-Development-Kit. This time the "F" stands for Firemonkey... - believe it or not...

Our Windows application had grown to many million lines of code. We are still using Delphi 2007, but we had to rewrite the core with our own unicode methods. New stuff is compiled with XEx to a DLL also some FMX-Stuff. So we could still uses our codebase. Over time many methods have been rewritten, but I think - if I just dig deep enough - I will find some lines of code just copied from the CP/M Version...

Since march 2017, I'm an Embarcadero MVP, after many years - just beta-testing delphi! (since 6.0).

Because FMX is kind of "still new" to many developers, I help other companies and developers with code-reviews and consulting. If you need help just give me a call or visit my website ( /

Yes, Pascal/Delphi has accompanied me through my life. If I hadn't been so lucky to make "some" money with my first Turbo Pascal application, Oh man, I should have learned a real job and worked properly.

This is my Delphi story and I hope I can use Delphi for many more years... Greetings to Embarcadero and of course to the friendly people working there - you are doing a great job. 

PS.: Please fix my QC's... ;-)

Tuesday, February 11, 2020

MVVM is just a concept.

It looks a little bit like a never-ending story, but it isn't.

Two things I realized after the "Pattern" is working.

1.) The main part of the implementation was the binding and also the hardest.
2.) With the D.MVVM-Framework in place, you have nothing to write a real app.


Yes, the only thing you have is some kind method creating the chain of Model -> ViewModel -> View and also binding the component properties to the ViewModel. Of course, this was the most work, but creating the flow of the app is also a necessary part. So what? Good question.

First of all, you need some really good startup/connect all/composition thing. That's why we call it composition root. This is the point where everything is hooked up together. At this stage, you can use a service locator to do your dependency injections. 

After your Main-Chain is running, how to do the program flow? How to load the next form from the View or the ViewModel? With a Navigation-Service! How can I fire some Button-Clicks? With an Action-Service! How to create a Main-Menü on the Main-View (without creating any dependencies?) With a Menue-Service. Dialog-Service... What else?

There might be some more services needed. But at the moment I'm able to do anything with a combination of these Services - Like a "You are not logged in" so fire up a Login-Dialog before loading the next Form/Frame.

At the Model stage ORM/CRUD Database stuff would be perfect. That's why I write this also as a plugin for my FDK because everything you need to do with the database stuff is already in place.

If you never tried this yourself, the best approach is to try a sample application. At this point I realized - yes all this framework stuff is just to be able to do a proper unit-testing and after two weeks of refactoring - lol - unit-testing is a piece of cake, after I created some Mock-Ups to kill the visual dependency's.

Before you are able to buy this framework, I will refactor some of my other projects - this real-life proof of concept will perhaps bring up some more needs, but every new project will do this, up to a point where I call it ready for shipment. 

At the start, my release date was February - but as always - other things got into my way. So it is ready if it is ready - sorry no prediction at this time. We will see. I hope that refactoring my other projects to the framework would only show up additional needs and not the need of changing the kernel. 

Any questions or ideas? That what I really need to put into the framework, please leave a comment.