So I'm not doing Delphi work any more, because pretty much the only jobs I get hired for are maintaining ancient legacy Delphi apps where the company generally refuses to allow us "experts" to do any sort of refactoring. Either that or it's like: "well, if we're going to rebuild it, there's no way in hell we'll use Delphi! We'd only consider C#/.NET in that case." I have personally never seen a single one of such redesigns ever completed on-time or within budget. But it's all that companies seem to think is warranted. Moving these horribly mutated ginormous desktop apps over to web apps without significant redesign is silly. What happens with these big desktop apps is they start out simple, then get warts added on top of warts until you have this huge, complex mess that's got all sorts of right-click options on virtually everything to deal with common needs that cannot be provided without severe change to the UI. There's also a lot of UI redesign that can be done to simplify different use-cases. Management sticks with what they know.įrom what I've seen in most apps I've supported, there's a ton of stuff that can be easily factored-out and moved into REST-based services. The whole thing could have been reimplemented in far less time as a REST-based service, but everybody thought that was just way too risky and that the performance would be really bad. I have no idea what it cost, but probably over $500k, and it ran over by 50% before they pulled the plug and the other dev on our team finished it up in a few weeks. One was slowly moving in that direction for newer things, but I saw a ton of resistance elsewhere.Īn earlier one was migrated from one DB to another. I know we could have done it in-house in about 4 months, but upper Management insisted they thought it would be better to outsource it. Is this a panacea for all of the humonguous apps historically built with Delphi that have been around for more than a decade? Hardly.īut the last three jobs I've had all implemented a ton of stuff in core parts of their systems that could be moved without too much trouble into service-based instances running inside their own network. TMS has also added the ability to encapsulate WebCore (or any web-based) apps to run as native apps using their Miletus technology. Lately I've been shifting my focus over to TMS WebCore because I believe the future lies in web apps for generalized cross-platform needs, rather than a hodge-podge of separate platforms that are all evolving so fast that keeping track of them all in parallel with moving the common platform forward is an expensive exercise in chasing one's tail just to stay current. Even an educational institution I worked at for nearly 5 years kept their Delphi license current and the project head refused to even consider FPC or Lazarus. They have language features that Delphi only dreams about, and they can be fun to play with. I have never been asked about either FPC nor Lazarus for use in any sort of production capacity. Since 1999, I've been hired numerous times because I'm an "expert" with DELPHI - not merely with Pascal. Procedure TForm1.Just curious to what the state is of both as viewed by 'expert' Pascal programmers Event handler pointer to our procedure My Wonderful Dynamic FormĪlso add just before this event handler, and after the following function: MyForm.Caption:=’My dynamic created form’ Procedure TForm1.Button1Click(Sender: TObject) Īdd the following code to this event handler: Add a TButton from the Standard Tab to the current Form1.Įdit Caption attribute from the just created Button1 element and change it to “Dynamic Form” (or what ever you want to name it).ĭouble click on the Button1 and the event editor will show up with the current code: Select Project | Application and Unit1 – Form1 shows up in the editor. Just click on File | New … and a Form opens up.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |