program begin end. // comments?

Hmm - you've got a point... I'll think a l...

2011-11-15T09:53:13.224+01:00

Hmm - you've got a point... I'll think a little about it and try from a different angle.

Dynamic jump tables: still a set, not a sort. ;)

2011-11-14T17:21:37.113+01:00

Dynamic jump tables: still a set, not a sort. ;)

Aye, it is a poor example. I'll provide a bet...

2011-11-10T00:06:33.216+01:00

Aye, it is a poor example. I'll provide a better one.

This actually was an old draft post, and it appear to me that I haven't quite completed my train of thought here. My need at the time was related to creating jump tables for handling data streams, partly statically defined at compile time, but revised at run time.

Your syntax is for sorting, but your use cases are...

2011-11-09T17:49:26.071+01:00

Your syntax is for sorting, but your use cases are all about set operations. Set operations do not require sorting - sets do require some manner of precomputing, but not display sequence ordering. Its best not to impose an implementation on the interface.

If you want presorted data, change your use case to show why this would be useful and how you would deal with locale and localization issues.

If you want set operations on arrays or vectors, lose the "ordered" syntax and just extend the existing "set of" syntax.

Sheesh - I look forward to G+ comments on Blogger ...

2011-11-09T09:36:41.213+01:00

Sheesh - I look forward to G+ comments on Blogger - hate that I can't edit them!

The page itself can be used to publish the current list of public followers bi-weekly, but that is not strictly necessary.

I am hoping that Google will add a functionality that allow followers to create a joint stream through a page, thus making pages into self-curating focal points, i.e. interest groups.

You are correct - currently only the owner of a pa...

2011-11-09T09:30:35.534+01:00

You are correct - currently only the owner of a page can post to the page.

The point of the User Group pages is that people can follow them in public, hence making the pages lists of people that would like to be considered as a member of the respective user group.

The page itself can be used to publish the current list of followers bi-weekly, but.

That way you can add those of the visible users/pages you want to follow to your own Delphi circle.

Think of it as voluntary directories that are self maintaining. You can lurk, but if you want people to discover your Delphi posts, you should create your own Delphi page, and from that page, follow the relevant user group pages to become visible to other Delphi users.

Am I right that only the creator can post to a Goo...

2011-11-09T09:12:59.907+01:00

Am I right that only the creator can post to a Google+ page though? It's not much of a user group when it relies on only one person for its content.

I m think, VCL should never be compatible with Win...

2011-09-21T15:53:43.743+02:00

I m think, VCL should never be compatible with WinRT directly - only via legacy desktop part of Windows API.

Delphi RTL should be compatible with WinRT via new platform - for ex Windows.WinRT.* namespace, like MacOS API)

Regarding UI layer - don't know, no ideas. Maybe its best to produce some XAML-based bindings to new Win UI components, maybe the can port FireMonkey to Metro-like style.

And one more note: no text about OpenCL support, but logo is on screen)

I think we can say for sure that VCL will not span...

2011-09-21T15:28:48.539+02:00

I think we can say for sure that VCL will not span the WinRT Metro UI. We might be able to access WinRT non-visuals from a VCL App, but WinRT is the native Windows library reinvented - so in a way you can call it a new platform. Can the visual part of WinRT be wrapped in FireMonkey? Don't know. Lots of exploration and hard choices ahead for the Delphi team, me thinks.

I will be interested to see where things go with W...

2011-09-21T15:03:47.265+02:00

I will be interested to see where things go with Win8 support. It seems that Metro would require pure FireMonkey development. That's a natural solution for light Apps, but I think Metro will stink for heavy hitting business applications. (no overlapping windows - tiles - heavy on touch)

I'm wondering if there is a way that VCL will ever support direct WinRT. Supposedly Visual Studio will have native C++ compile to WinRT. There's a lot of existing code in the world that works much better in VCL and with traditional Windows handling.

I've had some new ideas - so I am gonna do a l...

2011-09-20T22:18:13.895+02:00

I've had some new ideas - so I am gonna do a little more work before I put it out there.

FYI: Ali Keshavarz has posted an informative artic...

2011-09-11T16:21:58.201+02:00

FYI: Ali Keshavarz has posted an informative article on the state of BiDi in FMX. http://vcldeveloper.com/news/firemonkey-and-support-for-bi-directional-text-2/

@Stefan: Well, I have two concerns. Conversion/val...

2011-09-08T16:32:35.540+02:00

@Stefan: Well, I have two concerns. Conversion/validation - which TValue would deal with nicely, and presentation - which TValue won't support. I am not in control of how many decimals my floats would be displayed with. For an input dialog that deals with volumes and weights, as well as other quantitative values - I need to be able to specify a number of decimals.

I think I will forgo the TValue version for now - and stick with the oldschool approach.

@Lars: With TValue you can't and I actually th...

2011-09-04T22:40:48.209+02:00

@Lars: With TValue you can't and I actually think that should not be the purpose of this. I can't say yet because I don't know where this is going, but so far I smell violation of SoC.

@ahmed - It is in there, but I really can't te...

2011-09-04T16:15:00.720+02:00

@ahmed - It is in there, but I really can't tell if it is working correctly as I have never used it, and I don't know anything about selecting the right font, the right locale, and the right text to see if it works or not.

@Dag - Yes, validation of data can be a very compl...

2011-09-04T14:28:09.017+02:00

@Dag - Yes, validation of data can be a very complex exercise.

I separating the validations into two different categories.

Basic, i.e. ensuring that a number is a number, a date is a date, etc. and Context - where we have to make decisions about the data in their validity in a contextual relation to other data.

The Basic validation is something we shouldn't have to re-implement umphteen times.

The Context validation will be specific to each dialog implementation.

As for dialog vs load/import validation - and repeated code - this is something that depend a lot on the application and use requirements. I have tried to make the model possible to adapt to different ways of doing the validation.

@Stefan - I have been thinking a little about usin...

2011-09-04T14:07:33.235+02:00

@Stefan - I have been thinking a little about using TValue instead of explicit types, but I wonder: how would I control individual formatting? Number of decimals for a float, as well as different date and time formats?

In a way you're right of course, late validati...

2011-09-04T13:03:44.144+02:00

In a way you're right of course, late validation can be very annoying and is not perceived as user friendly. Sometimes you can almost hear the user mutter "Why didn't you tell me so in the first place you stupid program!".

But the risk of dialog validation is that it will start out as a few minor restrictions but before you know it has grown and grown and grown ...

And no matter how small, when you load/import data the same checks must be performed which means double code.

And then there is the worst case of dialog validation: the graying out of a control without telling the user why. I can't really think of a single case where graying out is acceptable unless perhaps a hint is used to spell out why the control is disabled. But much better is, I think, to keep the control enabled and tell the user why he/she can't use it if and when it's clicked.

It's nice to note that although coding for user input and validation is pretty boring, thinking about how it best can be done is not. I often find that striking a balance between being too restrictive (but simple) and too flexible (and complex) is really hard ...

what is about bidimode property? is it obsoleted?

2011-09-03T22:16:38.137+02:00

what is about bidimode property? is it obsoleted?

@Dag - In principle, I agree - in practice, centra...

2011-09-03T15:47:11.699+02:00

@Dag - In principle, I agree - in practice, centralized validation can be unnecessary for operations only performed in a specific dialog.

What if you can do both?

Personally I believe that validation should not be...

2011-09-03T14:53:16.708+02:00

Personally I believe that validation should not be part of the input dialog itself. There are some exceptions, as always, most notably avoiding annoying the user with late validation instead of reacting immediately to user input.

But in general late validation is better and, in many cases, unavoidable. Getting the data from the user is just one slice of the cake, what happens when you start saving, reading, exporting and importing the data? In all those cases you need to validate the data before acting upon it. And code tied to a dialog won't do you any good. And surely you don't want to code something as boring a validation twice, you don't even really want to code it at all.

Many times, at least in my experience, dialog validation just doesn't cut it because the dialog doesn't know the whole story, just bits and parts. And sometimes you need more data to validate. Sure, you can send that necessary data to the dialog but that violates the principle of 'be a secretive as possible', i.e. don't spread you data around.

I usually create a TValidation object with at least one method, Validate. The code in TValidation generally turns out really awful but I think that can't be helped because it reflects real-life complexity and that tends to be messy.

One very nice, an unexpected, boon stemming from TValidation is that with time the code will come to act as documentation for whatever it is you're validating. It will have all the answers to questions like "If A and B are both greater than 10, C must be less - why was that again?". In some cases, my code has become the authority, especially concerning the more exotic aspects.

So, to briefly recap, validation should, in almost all cases, be done in a centralized place and not in the dialog.

@Francois - I did :) @Lachlan - I agree. I liked A...

2011-09-03T11:18:44.330+02:00

@Francois - I did :)
@Lachlan - I agree. I liked Andreas' suggestion of using a const. That would really improve the odds where there are multiple references.

Still to use XE2 myself but it occurs to me that e...

2011-09-02T22:17:55.223+02:00

Still to use XE2 myself but it occurs to me that even

MyObject.Bind(Src, 'SomeBooleanProperty');

makes it easier to spot necessary name changes than a TDBEdit.FieldName property inside the object inspector.

I haven't really spent much time with TValue, ...

2011-09-02T21:37:06.008+02:00

I haven't really spent much time with TValue, so that is probably something that I should look at closer.

I probably also should expand
IT - InputType
SVT - SourceValueType
CVT - ControlValueType

There still is a few "secrets" to this that I haven't revealed, which hopefully will explain the heavy use of parameters.

The goal is to have something that empower you to create smart dialogs with a relatively limited amount of code.

I have to agree with you. Actually LiveBinding doe...

2011-09-02T17:07:27.534+02:00

I have to agree with you. Actually LiveBinding does not deserve the binding in its name because it's implementation is just a shame compared to equal solutions in other languages.

I don't know what to think of your implementation but from just looking at the code I expect a huge bunch of binding code in the end. Also I think you are overusing generics here (not to mention the non telling names for your different type parameters). Then again you implement specific classes for like integer, string and so on where you could actually benefit from the generics if you would use TValue (don't tell me it's slow, we are talking about GUI) Actually the way you are going could even be implemented in Delphi 7 or earlier without using generics.

While I agree that the string approach is not desirable it cannot be don't any different right now if you want to write your software in a declarative way. Personally I don't want to write actual "classic" code to bind some Lastname property to a usercontrol. I just want to define it somewhere, be it naming the control Lastname, Person_Lastname or in any different declarative way. Because that in the end leads to reusable code and that can be shared for multiple projects ("Hey, look, I can reuse my EditUser Dialog") or for different UI elements ("Wow, Bob just created this new awesome twinkling FireMonkey User Dialog with rotating edits...")