BlueCell wrote:

Any news on the access driver?

The access driver will be released with this runtime update, it will approx take 2 days to create the driver, but because the templates are changed at the moment as well, I'll wait till the rest of the code is done so I don't have to port code over to yet another templateset each time I add a piece of new code

Any update on when the Beta period might start? There is functionality in the runtime revisions that we could really use on our current project...

mdisbrow wrote:

Any update on when the Beta period might start? There is functionality in the runtime revisions that we could really use on our current project...

I hope next week. The list of stuff to be implemented is getting shorter by the day, with 3 major things still left: paging, prefetch paths and fieldcompareset. These are related to eachother so are done at the last time so they don't have to be refactored when another feature is added.

If you REALLY want, I can send you a version of the runtime and templates, however it's in alpha so if you run into issues you'll have to wait till the beta to get them fixed. (I use unit tests to test the new features so the new stuff should be pretty ok, but there is no documentation yet, just unittest code). It's however recommended to wait till the beta.

Otis wrote:

If you REALLY want, I can send you a version of the runtime and templates,

Since the code we want is less likely to be refactored I'd like to start working with it now, since this code will probably be the same code we get in the Beta!

mdisbrow wrote:

Otis wrote:

If you REALLY want, I can send you a version of the runtime and templates,

Since the code we want is less likely to be refactored I'd like to start working with it now, since this code will probably be the same code we get in the Beta!

No that's not the case. You will run into problems with compiling against the final, you have to re-generate the code then. Also, if there is a revision in the expression class for example, you will have a problem as well. So using it now is just for getting it done now and realizing that you have some work to do when the final arrives.

Still want it?

The access driver will be released with this runtime update

First, let me just say this: WooHoo!

So, does this mean that the Access stuff will be out with the beta, or not until the release. If the release, when was that again?

I'm just about to start an Access WinForms client and would gladly beta your Access version. My project is going to do remoting, so it will be a really good exercise of the product.

Second, let me just say this: WooHoo! Having LLBLGen for Access will make this upcoming distastful task go easier!

Not that you arent already really busy Frans, but is there a SQL CE or MySQL Driver on the horizon?

swallace wrote:

The access driver will be released with this runtime update

First, let me just say this: WooHoo!

hehe

So, does this mean that the Access stuff will be out with the beta, or not until the release. If the release, when was that again?

Beta will be released, then access is created, and then the beta is updated. The final release of the runtime libs is not set, as I want to do extensive testing before it is released. This means that I want to have unittests for every functionality if possible. (I used a testprogram but I use unittesting now since a month or two and it really is a lot easier, so I have to port over the tests from my testprogram to the unittest project).

I'm just about to start an Access WinForms client and would gladly beta your Access version. My project is going to do remoting, so it will be a really good exercise of the product.

Cool. If the requirement is a server-less database, you can also think about Firebird embedded. This requires the firebird DQE build against v1.6.x of the firebird provider but then you can use the firebird db without a server.

Devildog74 wrote:

Not that you arent already really busy Frans, but is there a SQL CE or MySQL Driver on the horizon?

CE: later this year MySQL: when the runtime lib updates are released, new drivers will be made, among them MySQL (unless it sux that much that it's not possible)

If the requirement is a server-less database, you can also think about Firebird embedded.

It is server-less, and I'll take a look at Firebird since I didn't know they had an embedded version, but I don't mind waiting a bit for the Access stuff. Better to go with what you know.

I look forward to it.

swallace wrote:

If the requirement is a server-less database, you can also think about Firebird embedded.

It is server-less, and I'll take a look at Firebird since I didn't know they had an embedded version, but I don't mind waiting a bit for the Access stuff. Better to go with what you know. I look forward to it.

Heh Well, if you like Access that much . If I could avoid Access I'd do it without hesitation.

/// <summary>
/// Tests a more complex usage of the fieldcompareset predicate: Get employee with the last order they closed.
/// SELECT  E.EmployeeID, O.OrderID
/// FROM    Employees E INNER JOIN Orders O
///         ON E.EmployeeID = O.EmployeeID
/// WHERE   O.OrderId =
///         (
///             SELECT TOP 1 OrderId FROM Orders 
///             WHERE EmployeeID = E.EmployeeID
///             ORDER BY OrderDate DESC
///         )
/// </summary>
[Test]
public void FieldCompareSetTestComplex()
{
    DataAccessAdapter adapter = new DataAccessAdapter();
    ResultsetFields fields = new ResultsetFields(2);

    fields.DefineField(EmployeeFieldIndex.EmployeeId, 0, "EmployeeId", "E");
    fields.DefineField(OrderFieldIndex.OrderId, 1, "OrderId", "O");

    try
    {
        IRelationPredicateBucket bucket = new RelationPredicateBucket();
        bucket.Relations.Add(EmployeeEntity.Relations.OrderEntityUsingEmployeeId, "E", "O", RelationWeaknessHint.None);
        bucket.PredicateExpression.Add(new FieldCompareSetPredicate(
            EntityFieldFactory.Create(OrderFieldIndex.OrderId), null,
            EntityFieldFactory.Create(OrderFieldIndex.OrderId), null,
            SetOperator.Equal,
            new FieldCompareExpressionPredicate(
                EntityFieldFactory.Create(OrderFieldIndex.EmployeeId), null,
                ComparisonOperator.Equal,
                new Expression(fields[0])),
            null, 
            "O",
            1,
            new SortExpression(SortClauseFactory.Create(OrderFieldIndex.OrderDate, SortOperator.Descending))
            ));

        DataTable tlist = new DataTable();
        adapter.FetchTypedList(fields, tlist, bucket);

        Assert.AreEqual(9, tlist.Rows.Count);
    }
    finally
    {
        adapter.Dispose();
    }
}

(functionality is shown in adapter, but it's available to selfservicing as well)

The FieldCompareSetPredicate has per template group 10 constructors. It's a bit much to add it to the PredicateFactory class, as that would inflate that class with a lot of code if the project is a bit large. So I'm thinking of not included this predicate in that class.

SetOperator has also operators like Exists, EqualAny, GreaterEqualAll etc., and combined with the expression support for both field compared as well as the field in the subquery (which can contain subqueries), I think the filtering options are limitless now and there won't be a lot of situations where you need a stored proc or view to get things done (ex: you can now produce: ... WHERE ((Foo + Bar) * 3) > ALL (Select (Bar + 2) FROM bla WHERE...) etc.)

I'm not completely sure, but with this power the filtering of LLBLGen Pro looks like one of the most powerful at the moment I hope to have the beta next week, as some things still have to be implemented (but we're getting close now )

Another example: (which can be done today already, with a join (which is more efficient in most cases, but just for testing's sake ))

/// <summary>
/// Tests the FieldCompareSetPredicate using a simple subquery.
/// select * from products where productid not in (select productid from [order details])
/// or: all products which are not sold in an order.
/// </summary>
[Test]
public void FieldCompareSetTestSimple()
{
    DataAccessAdapter adapter = new DataAccessAdapter();

    try
    {
        IRelationPredicateBucket bucket = new RelationPredicateBucket();
        bucket.PredicateExpression.Add(new FieldCompareSetPredicate(
                EntityFieldFactory.Create(ProductFieldIndex.ProductId), null,
                EntityFieldFactory.Create(OrderDetailsFieldIndex.ProductId), null,
                SetOperator.In,
                null, 
                true));
        EntityCollection notSoldProducts = new EntityCollection(new ProductEntityFactory());
        adapter.FetchEntityCollection(notSoldProducts, bucket);

        Assert.AreEqual(3, notSoldProducts.Count);
    }
    finally
    {
        adapter.Dispose();
    }
}

Design time support for collections is put on hold for the moment, I can't find ANY documentation to get this right. I have something working based on the templates Ruizzi supplied but these have some problems and don't work in adapter.

If someone can supply me some URLs to articles what to do, I'd be very happy

Have you tried using the modification that I posted to the forums regarding his template? I don't think he did a couple things right but the modifications I've been using have worked well (at least with SelfServicing.)

Edit: These are the changes I'm speaking of: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=936

Awesome, totally forgot about that! Thanks, will check it out!

Another thing to note: When you're implementing the Component for a TypedList or TypedView, when implmenting the IListSource.GetList method, just return a ((IListSource)myTypedList).GetList(); Don't know if that would have been immediately obvious to you, but it wasn't to me.

Thanks for the info I really couldn't find any info on this, do you have any links to articles about this?

No Everything I know about Design-time stuff I've learned just by endlessly fooling around with it. Might as well be asking for the keys to the MS kingdom.

Heh Ok, well, at least I've got your template, should bring SOMETHING

Glad to be of assistance... Let me know if you have any problems with it.

Perhaps I'm doing something wrong, but I can't set the column mapping name in a column style with the vanilla .NET grid, when I use your modifications (get the same results): Specified method is not supported. Any ideas why/which method is meant?

With the Janus grid I'm able to fully design the appearance with the designer, which is very cool. For adapter this will be a task impossible to fulfill without a full blown designer in vs.net, so I'll leave it at that for now.

I've signed up for the VSIP program (that's now free) and have downloaded the VSIP SDK. I hope that has more info on the matter

(edit). Not a single word in there, just add-in stuff on the level of COM. I give up for now besides the small droppable object.

Ok found this: http://www.freeweb.hu/noiseehc/IListSource.html

This code works. I tried to write a simple class which would mimic his wrapper, but that doesn't work. Really strange. But nevertheless, I finally have found something that does work so I can try to fix up the code I have.

Adapter should be possible too btw, with 1 mockup class per entity. (all these things are really mockups, you shouldn't use the objects created, just use them to design the grid)

Ok I give up. After hours of trying I can't find what's wrong with my code. I can't find a single line of documentation on this and it is now becoming very frustrating.

I can get with a few lines of code the properties to show up in the grid (say, the properties of a customer entity show up in the grid when I use a customercollection mock up), however I can't select a datamember (like 'Orders') I get 'Specified method is not supported'. I don't know what's wrong, I implement all the interfaces you can think of, but no luck.

Apparently this is very broken, looking at the lack of any documentation. The only results I find in Google groups are poor sods with the same problem as I have and NO replies.

-> Dropped, and unless someone can give me any hints, I won't look into this again... Sorry.

(ps: the code to make a customer collection bindable at designtime:

public class CustomerSource : Component, IListSource 
{
    bool IListSource.ContainsListCollection 
    {
        get {return false;} // nevermind, never called
    }

    IList IListSource.GetList() 
    {
        return _customers;
    }

    private CustomerCollection _customers = new CustomerCollection();
}

That's it. With more sophisticated grids, like the Janus GridEX, you can use this mockup to retrieve the structure, 1 level deep, but not deeper, despite the ITypedList implementation and what not.

In adapter it should be something like private EntityCollection _customers = new EntityCollection(new CustomerEntityFactory());

Ok, retried it, as I can't stand this (and it's too hot to do anything anyway). With just a customer and an order entity, it works. Really weird. So somewhere it blows up, but I don't know what. I'll add more entities now, to see where it goes wrong...

(edit): ok, when an entity has an m:n relation (and thus collection) it fails. So when I have: Customer, Order and Employee, Customer has an m:n relation with Employee. Also when I remove the Customers collection from Employee, it doesn't matter.

However, when I remove the Employee collection from Customer it works. Funny thing is... if I add a bogus property to OrderEntity which returns a CustomerCollection, it again gives the "Specified method is not supported" remark...

When I try it with adapter vs.net dives into an infinite loop... really weird. (and I'm now really giving up on this. )