See the forum: http://www.llblgen.com/tinyforum/Threads.aspx?ForumID=18&SectionID=2 See the customer area's runtime library section for the download (6MB). You need v1.0.2004.1 of the designer to participate in the beta.

Be sure to read the enclosed readme.htm before proceeding.

The features added are huge and will have a big impact on how you will use LLBLGen Pro. The enclosed unit test code will enlighten you more on how to use the new features, until the documentation is up to par.

The MS Access driver will be added to the beta later this week.

(and now I'll grab a beer )

WWWAAAAAAAAHHHHOOOOOOOOOO!!!!!!!!

Not bad for 2 months of work, my friend. Not bad at all! That's a rockin' feature list!

Can't wait to get my hands on this bundle o' love

Seriously. Just re-read the feature list. You...are...the...man. Sorry to be so prosaic, but that feature list reads like a "who's-who" of ORM features. It's everything I could have ever dreamed about...it's like Dorothy waking up in "The Wizard of Oz"...it's like warm snuffly kisses from a puppy...it's...it's...

LOL

Yeah I hope it's useful

Really cool.

Thanks Frans.

You know, I haven't tried it yet, but I'm thinking the new "revert" and "save changes" functionality may be useful in changing out datasets for entity collections in so-called "Smart Client" scenarios (occasionally connected Windows Forms applications). The great things about datasets in this environment were the "RowState" property and the "AcceptChanges" and "RejectChanges" methods (I think those are the right names) that allowed one to hold data in the datasets as a cache until the application was reconnectd to the data source.

I'm pretty sure this isn't how Frans intended it to be used, but I think this is a big deal. This will also help a lot for future Pocket PC support which is a Smart Client almost by definition.

IMHO, Smart Client functionality is where the future is at. The industry may decide to agree on a web-based presentation standard, but it's still inherently a server-based technology. Rich clients+web services gives one the presentation richness of Windows Forms, and the reach of the internet.

Just a thought...

Jeff...

jeffreygg wrote:

You know, I haven't tried it yet, but I'm thinking the new "revert" and "save changes" functionality may be useful in changing out datasets for entity collections in so-called "Smart Client" scenarios (occasionally connected Windows Forms applications). The great things about datasets in this environment were the "RowState" property and the "AcceptChanges" and "RejectChanges" methods (I think those are the right names) that allowed one to hold data in the datasets as a cache until the application was reconnectd to the data source.

That's the idea indeed: to make it easier for applications to manage state of entity data outside the database.

I'm pretty sure this isn't how Frans intended it to be used, but I think this is a big deal. This will also help a lot for future Pocket PC support which is a Smart Client almost by definition.
IMHO, Smart Client functionality is where the future is at. The industry may decide to agree on a web-based presentation standard, but it's still inherently a server-based technology. Rich clients+web services gives one the presentation richness of Windows Forms, and the reach of the internet.

But isn't the small screen on a pocketPC almost making that richness pretty moot? (I mean: for such a small screen, a webapp can be rich as well). A webapp has the advantage as well that you don't have to write 2 clients.

Otis wrote:

But isn't the small screen on a pocketPC almost making that richness pretty moot? (I mean: for such a small screen, a webapp can be rich as well). A webapp has the advantage as well that you don't have to write 2 clients.

Hmmm...lots of thoughts on this:

Otis wrote:

But isn't the small screen on a pocketPC almost making that richness pretty moot? (I mean: for such a small screen, a webapp can be rich as well).

While the size of the screen may or may not diminish the utility of a rich client (I don't think it does), the fact that HTML, CSS, CSS2, DHTML are horrible presentation tools makes rich client functionality that much more relevant in today's ongoing push for abstraction. This isn't to say that HTML, CSS, CSS2, and DHTML can't duplicate rich client functionality (witness OWA 2003), it just takes an insane amount of work to do it - besides the fact that web programming is inherently stateless. But, why program in these poor languages when there are so many more appealing options?

A webapp has the advantage as well that you don't have to write 2 clients.

Well, I may be an idealist , but I'm assuming at least one of either Java or .NET is going to win out. It just doesn't make sense not to have a write-once/run-anywhere platform to program against - the commoditization of the hardware architecture underlying the software platform has to win out. As for the fact that the Compact Framework is a subset of the complete framework, I don't think it will be for long. While the presentation layer will always need to be rewritten to account for the limited screen real estate, it's obvious that the main reason for having to create a subset for pocket devices - limited memory - will not soon be an issue. It's only a matter of time. The presentation layer will still need to be rewritten for both clients, but that would apply to web apps as well, as the device's screen size doesn't change based on the presentation technology being used .

Finally, web apps still don't take into account the definition of a Smart Device as an "occasionally connected device". By definition, if the server isn't available, the web app can't run.

I do think that the current standard of web presentation has it's place - as a simple storefront. It's lightweight, and relatively easy to debug (although HTML must be replaced at some point). But for any real functionality, I don't think one can beat an on-demand rich client deployed to a nice and cozy sandbox on the client device utilizing the internet for what it was meant to be - a communications device not a presentation device.

Jeff...

jeffreygg wrote:

Otis wrote:

But isn't the small screen on a pocketPC almost making that richness pretty moot? (I mean: for such a small screen, a webapp can be rich as well). A webapp has the advantage as well that you don't have to write 2 clients.

Hmmm...lots of thoughts on this:

Otis wrote:

But isn't the small screen on a pocketPC almost making that richness pretty moot? (I mean: for such a small screen, a webapp can be rich as well).

While the size of the screen may or may not diminish the utility of a rich client (I don't think it does), the fact that HTML, CSS, CSS2, DHTML are horrible presentation tools makes rich client functionality that much more relevant in today's ongoing push for abstraction. This isn't to say that HTML, CSS, CSS2, and DHTML can't duplicate rich client functionality (witness OWA 2003), it just takes an insane amount of work to do it - besides the fact that web programming is inherently stateless. But, why program in these poor languages when there are so many more appealing options?

Ok, you're right Personally I do hate the 1994'ish style of webgui's which are still the same today. (back in those days it was HTML forms with textboxes and checkboxes and that hasn't changed a bit). XAML perhaps changes that, but the more MS cuts off longhorn the more I doubt it will ever change...

In that case, you're absolutely right: a platform which offers easy to develop rich clients is preferrable.

A webapp has the advantage as well that you don't have to write 2 clients.

Well, I may be an idealist , but I'm assuming at least one of either Java or .NET is going to win out.

No, I dont think so. And you should hope you're wrong too. The problem is: Java is so much bigger than .NET, you won't believe it. Microsoft's hype machine makes it look like everybody and his brother is doing .NET these days but that's far from the truth. I mean: Java is on embedded systems for years already, AND all the way down inside the big iron databases for years (db2/oracle).

So what I foresee is this: Java will stay the top, and .NET will be there as 2nd player due to MS's amount of money that's invested in it.

It just doesn't make sense not to have a write-once/run-anywhere platform to program against - the commoditization of the hardware architecture underlying the software platform has to win out.

Only for the client, I never believed in the write-once/run-anywhere slogan, ok just for a few months in 1994 when java came out....

As for the fact that the Compact Framework is a subset of the complete framework, I don't think it will be for long. While the presentation layer will always need to be rewritten to account for the limited screen real estate, it's obvious that the main reason for having to create a subset for pocket devices - limited memory - will not soon be an issue. It's only a matter of time. The presentation layer will still need to be rewritten for both clients, but that would apply to web apps as well, as the device's screen size doesn't change based on the presentation technology being used .

Agreed Although the compact framework doesn't need a lot of .NET classes btw, but as these are namespaced (but not assembly separated, oh microsoft, why o why) it shouldn't be a big problem... (but why it isn't done now is beyond me)

I do think that the current standard of web presentation has it's place - as a simple storefront. It's lightweight, and relatively easy to debug (although HTML must be replaced at some point). But for any real functionality, I don't think one can beat an on-demand rich client deployed to a nice and cozy sandbox on the client device utilizing the internet for what it was meant to be - a communications device not a presentation device.

Still, I think for a LOT Of applications the compact device is simply too small. For applications which need a device 'on site', like a device carried by a worker in the storage facility or on site, but for client apps used by the vast majority of users: mom and pop sixpack, I think the compact framework is overhyped. Don't forget, this isn't new. In the javaworld this is going on for years already. Ok, fairly recently the cell phones people have can do more than 10 years ago, but still... perhaps it's me but I'd rather use a palm pilot to access services than a 1" screen on a cellphone...

Otis wrote:

Ok, you're right Personally I do hate the 1994'ish style of webgui's which are still the same today. (back in those days it was HTML forms with textboxes and checkboxes and that hasn't changed a bit). XAML perhaps changes that, but the more MS cuts off longhorn the more I doubt it will ever change...

You know, this may not be the popular opinion , but the fact that HTML is still the de facto presentation standard on the internet is a direct result of it's open source-ness. Nobody had a direct, vested interest in making sure a real presentation language was used, and so HTML was extended, and extended, and extended so that we're now left with this crap cludge, instead of a rich and lightweight language. That's not to say that we didn't have lessons to learn before we could develop such a language, but it should have been in place a long time ago. Personally, I think XAML or something similar is going to be the presentation standard for web (server-based) and non-web (client/server based) deployments.

No, I dont think so. And you should hope you're wrong too. The problem is: Java is so much bigger than .NET, you won't believe it. Microsoft's hype machine makes it look like everybody and his brother is doing .NET these days but that's far from the truth. I mean: Java is on embedded systems for years already, AND all the way down inside the big iron databases for years (db2/oracle).

So what I foresee is this: Java will stay the top, and .NET will be there as 2nd player due to MS's amount of money that's invested in it.

But, you do think one of them will win, right? I guess I mean that I believe that the managed and platform-independent framework (whether it's .NET, Java, or none of the above) will become the new standard for business programming. Thus, the practice of rewriting code for different target platforms will become obsolete.

Only for the client, I never believed in the write-once/run-anywhere slogan, ok just for a few months in 1994 when java came out....

I think it has to . I agree that the server will never become commoditized - ok, maybe it will when grid computing becomes a reality - but the client machine is next on the list after ICs, motherboards, expansion cards, processors, etc, etc. I think Google knows what it's doing with the rumors of the networked OS (whatever that is). At least it sounds about right, and I'm expecting that it will run on anything and soon the client machine won't matter. To be honest, the next stage could be for the OS itself to be commoditized. It's kind of out there, but I'm betting that both MS and Google sees this and is betting on it. MS may/will become divested, the core OS services may/will become a licensed thing, and MS will continue it's penetration of other core platforms. Like media standards and the home entertainment industry. I know, I know, it's out there...

Agreed Although the compact framework doesn't need a lot of .NET classes btw, but as these are namespaced (but not assembly separated, oh microsoft, why o why) it shouldn't be a big problem... (but why it isn't done now is beyond me)

You're saying that the CF stuff isn't in a physically different assembly than the regular stuff? Are you talking about mscorlib, or the ancillary assemblies? Or both?

Still, I think for a LOT Of applications the compact device is simply too small. For applications which need a device 'on site', like a device carried by a worker in the storage facility or on site, but for client apps used by the vast majority of users: mom and pop sixpack, I think the compact framework is overhyped.

I'd have to agree with that. I believe it will always be around as a niche player (it's great for things like asset/inventory management and tagging and so forth), but it definitely was overhyped. Rather, I see the Tablet form factor becoming the bigger player in this space. I know some believe that Tablet functionality should be wrapped into the standard laptop - which is good - but I think something like a 4 inch by 8 inch tablet is going to be be huge in the vertical markets. Something that costs US$500 - $600. Nevertheless, the CF was/is a great proof of concept of write-once/run-anywhere. Not 100%, but pretty good... If only we could get a decent ORM tool on there...

Jeff...