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 to "short".

The other Idea was to convince people to buy my Framework. While first customer where 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. To 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. First time I'm using the PDF stuff from my friends at Gnostice.

While talking to Craig Chapman he ask my 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.

Would'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 tables 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 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 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 tweeking 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 markt segment with a windows version. Everybody else were 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 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 this devices in our main app. This was the third heart attack - because nobody had support for these kind 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 ist 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 uses 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 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 "Your 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 live prove 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 Februar - 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 kernal. 

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

Thursday, January 30, 2020

TDD - I hate if I do not follow my own rules.

TDD or Test Driven Development is one approach for creating new software, modules, classes or whatever you need in your application.

The main idea behind this is to write your unit-tests first and then your productive code. Sometimes you need to change your tests because while developing the business stuff, you get new ideas on how you get the results you need. But this's fine.

Every time I do consulting in other companies or in my Delphi talks, I tell everybody: "Do your test first, because your development is much quicker" - "And you feel better" - "If every test is green (OK) you can ship the application".

There were complicated classes in the past for my FDK - it had taken more than twice the time to develop them if I hadn't used TDD. And yes, if you do the tests first, it will save you time. So far, so good. Of course, I don't follow my own rules 100% of the time. Sometimes it feels like - this is so simple; I don't need a test for this... In most cases this is correct - not good, but correct. 

Nearly every app has a point where you have to do more complicated things and like to do some unit-testing. Maybe not for the first release, but if you or your users find the "first" bug, it would be nice if you could write a test to reproduce the bug. Then fix the bug and confirm your test with the OK from your unit-test.

An here's the problem. While creating the unit-test-project you notice, that you have more dependencies in your application than expected. Just one little test and you need to link 90% of the app. Horrible! If you've done the tests in first hand, you probably had used more dependency injection. Changing that later is a real pain.

And then?

Your first look into your source code - OMG - What have I done... Yes, I found the problem, but are there any side-effects? Home much unit-test coverage do you have?

OK Frank - Next time write your tests first..!

Yes, this is an old app from the time where I do not had a MVVM-Framework, but this is no excuse!

Site note:   Assert(TThread.CurrentThread.ThreadID = MainThreadID); Is very helpful if you are using threads - and I hope with FMX you do everything you can do in a background thread! - Because you sometimes use a class or anonymous procedure in an event from a thread, you haven't done before.

Saturday, January 18, 2020

I wiped my development brain!

Holiday time... Brain-wash time...

At my last holiday I had no PC / Notebook with me. Just my phone - of course...

But my fear was to forget necessary parts I want to develop/fix/build in the next month. So I took a notebook (paper) and a pen and wrote down some ideas.

Every day I had some topics to write down... The interesting part was I found many topics - like new functions for my FDK that could be used in many old and coming projects. Same with a function that I need for a actual project could also fit in an app that I will start in the next few month. I just wouldn't have noticed that from memory.

After some days of reading the notebook and adding hints, there was a point where I read for hours, but did not add anything. So I put this notebook into my nightstand and I felt that my brain was completely wiped of development thoughts.

At this point the real holiday starts - interesting - I hadn't had this kind of empty brain feelings since many years.

So back home - I really want to keep this feeling... But how. At first I only read the topics from this notebook that are marked as "todo first". I did not read any development related topics - so far. wow...

I use JIRA for my main applications as a ticket system, but for project coordination I never used any software/website. (As I mentioned in last blogpost "Time Shared Development Part II".

I googled very hard to find an app with a reasonable price, but I found NOTHING. So if you are using a nice software for this use case, please leave me a comment or/and please fill out my survey!

I do not want to fill my brain with all the stuff from this notebook - I really want to use a software like: "I have 3 hours, what is the most important part I could development in the time frame?"  or "Give me a list of methods I need most for most of my actual and upcoming projects, order by estimated time of development"  or "Are there any classes I have to develop for the next release of my apps".

I'm really short of doing the perhaps most stupid decision - New / FMX App / Save as "Project H"...

I hope I have enough important things to do and in the meantime find a solution for my project management...


Perhaps you are also looking for a solution and many other developers, too... So we could start "Project H" together... Or you like to buy this kind of software for you or your team... Try to convince me to start this project...

There are 3.5 Mio Delphi developer out there - if just 1% would love to have this sourcecode for x €.

That would help... ;-)

Or my first open source project? Please help me with this survey!