clinq Forum Rss Feed

New Post: CLINQ for .NET 4.0

Natxo — Wed, 26 Dec 2012 16:41:02 GMT

I can tell that nsulikow's answer solves those warning issues. Good job man.

New Post: CLINQ for .NET 4.0

nsulikow — Fri, 17 Aug 2012 22:31:58 GMT

Just change Curry.tt so that the for loops start at 17 (because .Net 4 already has the first 16 definitions)

namespace System
{
<#for(int i=17;i<=20;i++){#>public delegate TResult Func<T1, T2, T3, T4, <#FormatRange("T{0}, ", 5, i); #>TResult>(<#FormatRange("T{0} t{0}", ", ", 1, i);#>);
<#}#>

<#for(int i=17;i<=20;i++){#>public delegate void Action<T1, T2, T3, T4, <#FormatRange("T{0}", ", ", 5, i); #>>(<#FormatRange("T{0} t{0}", ", ", 1, i);#>);
<#}#>
}

New Post: Another GroupJoin bug

balexander — Fri, 17 Aug 2012 19:33:55 GMT

Try the following code:

    public class GroupJoinTestFixture
    {
        public class WrappedString : INotifyPropertyChanged
        {
            public WrappedString(string s)
            {
                Value = s;
            }

            public string Value { get; set; }

            #region Implementation of INotifyPropertyChanged

            public event PropertyChangedEventHandler PropertyChanged;

            #endregion
        }

        [Test]
        public void Test()
        {
            ObservableCollection outer = new ObservableCollection { new WrappedString("hello"), new WrappedString("aloha") };
            ObservableCollection inner = new ObservableCollection { new WrappedString("hello"), new WrappedString("aloha") };
            ReadOnlyContinuousCollection inner2 = inner.Where(ws => ws.Value != "");

            ReadOnlyContinuousCollection>> join =
                outer.
                    GroupJoin(inner2,
                              outerItem => outerItem.Value,
                              innerItem => innerItem.Value,
                              (outerItem, innerList) => new RichKeyValuePair>(outerItem, innerList));
            var hasInners =
                join.Where(pair => pair.Value.Count > 0);
            outer.Clear();
            outer.Add(new WrappedString("hello"));
            outer.Add(new WrappedString("aloha"));
            inner.RemoveAt(1);
        }
    }

After the last line (inner.RemoveAt(1)) there should be only one item in the hasInners list. But there are two.

When we clear the outer list, GroupJoinReadOnlyContinuousCollection.OnOuterReset is called. It calls RebuildAll which in turn calls RebuildAllInner. But there's no need to rebuild the _keyToInnerLookup, and doing so creates redundant entries in it.

The fix is that OnOuterReset should call RebuildAllOuter instead of RebuildAll.

New Post: GroupJoin bugs?

balexander — Tue, 29 May 2012 13:59:04 GMT

I'm seeing some bad looking behavior in GroupJoin.

In the constructor, there is:

_outerReferenceTracker = new ReferenceCountTracker<TOuter>(outer);
RebuildAll();

If the 'outer' list is non-empty, the first line fill _outerReferenceTracker. Then, RebuildAll re-adds everything in _outer. It does not clear _outerReferenceTracker first. The end result is that every item has a reference count of 2.

An unrelated problem is in RemoveOuter, where there's the line:

List<OuterEntry> outersMatchingKey = _keyToOuterLookup[outerEntry.Key];

It appears to me that _keyToOuterLookup is not being updated when an outer item's key changes. I encountered this when I changed the key of an outer item, and later Removed that outer item. RemoveOuter tries to find the key in _keyToOuterLookup, it's not there, and an exception is thrown.

Even if someone's code doesn't encounter this exception, the fact that items have an extra reference count and key changes are not tracked leads to _outerReferenceTracker and _keyToOuterLookup containing no-longer-used information.

New Post: SortingReadOnlyContinuousCollection - ItemChanged

claudioganahl — Thu, 17 May 2012 09:25:25 GMT

When a property of an item changes, the SortingReadonlyCollection removes it and adds it again at the new position. Two events are sent to any subscriber.

Org Code in SortingReadOnlyContinousCollection:

void OnItemChanged(object sender, INotifyPropertyChanged itemThatChanged)
{
TSource item = (TSource)itemThatChanged;
RemoveItemFromOutput(item);
InsertItemInSortOrder(item);
}

The problem occures, when you f.e bind a SortingReadonlyCollection to a grid. You lose the SelectedItem on the grid, as soon the collection gets reorderd - because the item is removed (for a short time) from the ItemsSource.

I think it would be better to do the removing/adding just within the SortingReadonlyCollection and fire one CollectionChanged event with the action Move (like the ObservableCollection<T> does)

New Code:

void OnItemChanged(object sender, INotifyPropertyChanged itemThatChanged)
{
TSource item = (TSource)itemThatChanged;

int oldIndex = this.Output.IndexOf(item);
this .Output.RemoveAt(oldIndex);
int newIndex = this.Output.BinarySearch(item, this.KeySorter);

if(newIndex < 0)
{
newIndex = ~newIndex;
}

this.Output.Insert(newIndex, item);

if (oldIndex == newIndex)
return;

FireMoveItem(item, newIndex, oldIndex);
}

Addidional Method in ReadOnlyContinousCollection:

protected void FireMoveItem(T item, int index, int oldIndex)
{

FireCollectionChanged(new NotifyCollectionChangedEventArg(NotifyCollectionChangedAction

.Move, item, index, oldIndex));
}

New Post: Bug in ClearSubscriptions?

balexander — Wed, 25 Apr 2012 19:10:28 GMT

Hi,

I had a situation where I had one item in an ObservableCollection that was being used in a CLINQ expression. I cleared the ObservableCollection, then re-added that same item. I got an exception in NotifyCollectionChangedMonitor.SubscribeToItem at the line that says:

this.Subscriptions.Add(item, subscriptionTree);

The exception was that the key already exists, and sure enough, 'item' was already in the Subscriptions dictionary.

If I changed the Clear of my ObservableCollection to a RemoveAt(0), then re-added the item, CLINQ worked fine.

When I do the RemoveAt, NotifyCollectionChangedMonitor.UnsubscribeFromItem gets called and it has a line that says:

this.Subscriptions.Remove(item);

But if I call Clear instead of RemoveAt, NotifyCollectionChangedMonitor.ClearSubscriptions is called and it does not appear to clear the Subscriptions dictionary.

Is this a bug?

Thanks,

Bob Alexander

New Post: Veteran C# .NET LINQ newbie C++/CLI CLINQ

mwpowellnm — Fri, 23 Sep 2011 18:03:31 GMT

I should also add, we're using Visual Studio 2008 / Visual C++ for its C++/CLI features (among other things). Which it seems CLINQ will support?

New Post: Veteran C# .NET LINQ newbie C++/CLI CLINQ

mwpowellnm — Fri, 23 Sep 2011 17:43:30 GMT

This primer looks like as good an introduction as any to demonstrate the issue. I think that basically unlocks what I need to do.

The Linq between C# and C++

New Post: Veteran C# .NET LINQ newbie C++/CLI CLINQ

mwpowellnm — Fri, 23 Sep 2011 17:38:52 GMT

CLINQ'ers,

I'm sure you get asked this from time to time. Where should a veteran C# .NET LINQ developer begin as a C++/CLI CLINQ newbie?

Briefly, I've got some classes in a C++/CLI library that are exposing some IEnumerable<> results given a Dictionary<> backing field. I would like to ask a series of questions about that dictionary exposed through the enumerations. It seems CLINQ a strong viable approach to accomplishing this task?

Where might I find some documentation? Or I just downloaded the source itself as well. Or for some tutorials? Throughout Codeplex?

Thanks...

Best regards,

Michael

New Post: WeakPropertyBridge.CheckForUnsubscribe

PombeirP — Mon, 19 Sep 2011 14:20:10 GMT

I am chasing memory leaks on my app, and noticed there are quite a few related to ReactiveObject. In looking at WeakPropertyBridge.CheckForUnsubscribe, I noticed that calls to it are commented out, and not maitained for a while (they don't compile correctly anymore in uncommented). What is the reason for the call to be commented out? Is there any other place in the code that is doing that job? Is doesn't look like it to me...

New Post: Inserts into a collection are registered as add

jefflowe7 — Mon, 22 Aug 2011 16:20:19 GMT

Consider the following query:

ContinuousItemList = from item in Model.ItemList select new ItemViewModel(item);

Now say that there are 5 items in the list. If I execute the following code, the item inserted at index 2 of Model.ItemList appears at the end of the ContinuousItemList. As a result the order across the two lists is not consistent.

Item item = Model.Items[0];

Model.Items.RemoveAt(0);

Model.Items.Insert(2, item)

Am I doing something wrong? Is this a known problem? Is there a workaround?

Thanks,

-Jeff

New Post: CLINQ for .NET 4.0

nallenwagner — Thu, 10 Mar 2011 18:20:33 GMT

I too would like to see this happen. We are using this in a .NET 4.0 project, so we ended up making the necessary source changes ourselves.

For the System.Action issue, we changed the Curry.tt file so that it didn't generate as many variations of the System.Action delegates. I think that was the only thing we had to do to get it compiling under .NET 4.0.

We've made a couple other tweaks here and there too. I'd prefer not to do so, but there hasn't been a lot of response from the project contributors so far. I'm hoping they are still keeping an eye on this project. If not, maybe the community could pick it up.

- Nathan

New Post: CLINQ for .NET 4.0

rea5245 — Thu, 10 Mar 2011 17:13:39 GMT

I'm upgrading my project to .NET 4.0 and, while CLINQ appears to run, it triggers warnings that "The predefined type 'System.Action' is defined in multiple assemblies in the global alias; using definition from 'c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\System.Core.dll'"

I believe this is caused by ContinuousLinq's references to 3.5's System.Action conflicting with the rest of my project's references to the 4.0 version.

I tried recompiling ContinuousLinq for 4.0, but that caused a runtime exception in SmartFilterAdapter that I don't know how to solve.

Are there any plans to recompile and validate CLINQ for .NET 4.0?

Thanks,

Bob

New Post: Suggestion - Remove or Relocate extension methods that operate on ObservableCollection

Natxo — Tue, 22 Feb 2011 09:28:50 GMT

To me the cleanest option is not adding "using ContinuousLinq" and use it explicitly where you need it:

public ContinuousLinq.ReadOnlyContinuousCollection<foo> foos;

New Post: Where() on Items that dont implement INotifyPropertyChanged

ThomasHaller — Mon, 21 Feb 2011 22:28:27 GMT

Hello Lector,

i have got the same problem.

i made a small research and it seems that changing the objects used in the where-clause does not end with an Updating of the list as suspected

i made a small wpf application that demonstrates this. its a WPF App.

does anyone know if Clinq will get developed any further to support such scenarios ??

MainWindow.xaml.cs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Data;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Imaging;
using System.Windows.Navigation;
using System.Windows.Shapes;
using System.ComponentModel;
using ContinuousLinq;

namespace ClinqTest
{
    /// <summary>
    /// Interaction logic for MainWindow.xaml
    /// </summary>
    public partial class MainWindow : Window
    {
        System.Collections.ObjectModel.ObservableCollection<Cow> cowList =
                new System.Collections.ObjectModel.ObservableCollection<Cow>();


        public Cow CompareCow { get; set; }

        public IEnumerable<Cow> CowList
        {
            get
            {
                return from x in cowList where CompareCow == null || x.Name == CompareCow.Name select x;
            }
        }
                
        public MainWindow()
        {
            CompareCow = new Cow("Hansi");
            InitializeComponent();
        }

        private void Button_Click(object sender, RoutedEventArgs e)
        {
            cowList.Add(new Cow(newCowsName.Text));
        }
    }

    public class Cow : INotifyPropertyChanged
    {
        public Cow(string name)
        {
            m_name = name;
        }

        private string m_name;

        public string Name
        {
            get
            {
                return m_name;
            }

            set
            {
                m_name = value;
                if (PropertyChanged != null)
                {
                    PropertyChanged(this, new PropertyChangedEventArgs("Name"));
                }
            }
        }

        public event PropertyChangedEventHandler PropertyChanged;

        public override string ToString()
        {
            return Name;
        }
    }
}

MainWindow.xaml

<Window x:Class="ClinqTest.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="MainWindow" Height="350" Width="525" Name="self">
    <StackPanel>
        <ListBox Name="listBox" ItemsSource="{Binding ElementName=self, Path=CowList}"/>
        <TextBox Name="newCowsName" />
        <Button Content="Add Cow" Click="Button_Click" />
        <TextBlock>Filter this cow name</TextBlock>
        <TextBox Text="{Binding ElementName=self,Path=CompareCow.Name}"/>
    </StackPanel>
</Window>

New Post: vs version

joshkrak — Thu, 27 Jan 2011 01:49:17 GMT

Not sure what problems you're having but I had no difficulty in opening and upgrading the project to .net 4.0 in VS 2010 Ultimate

New Post: vs version

stefancelmicsisfa — Tue, 25 Jan 2011 09:30:23 GMT

hello,

none of the projects that come with clinq will open in vs 2010 ultimate or vs 2008 express, neither .net f 3.5, nor .net f 4 (that's what i've got so far). (and those are no tiny projects to build from scratch). i'm still waitin' for my vs 2008 professional kit to download. will that version of vs do the trick? or do you have other suggestions i might try?

thank you

New Post: Suggestion - Remove or Relocate extension methods that operate on ObservableCollection

nallenwagner — Tue, 26 Oct 2010 18:24:49 GMT

Thanks. That's a nice option. I'll give it a try.

From: "ismell"
Sent: Tuesday, October 26, 2010 1:50 PM
To: nathan@alner.net
Subject: Re: Suggestion - Remove or Relocate extension methods that operate on ObservableCollection [clinq:229692]

From: ismell

One of the things I do is just cast your ObservableCollection to an IList.

var collection = new ObservableCollection<string>();
...
var find = ((IList<string>)collection).Where(o => o.BeginsWith("Hello")).OrderBy(o => o);

Read the full discussion online.

To add a post to this discussion, reply to this email (clinq@discussions.codeplex.com)

To start a new discussion for this project, email clinq@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

New Post: Suggestion - Remove or Relocate extension methods that operate on ObservableCollection

ismell — Tue, 26 Oct 2010 17:49:53 GMT

One of the things I do is just cast your ObservableCollection to an IList<T>.

var collection = new ObservableCollection<string>();
...
var find = ((IList<string>)collection).Where(o => o.BeginsWith("Hello")).OrderBy(o => o);

New Post: Suggestion - Remove or Relocate extension methods that operate on ObservableCollection

nallenwagner — Tue, 05 Oct 2010 17:01:17 GMT

I would like to suggest that the extension methods which extend ObservableCollection, could be removed or relocated to a separate namespace. This would allow me to have continuous linq based statements in the same class as BCL System.Linq queries. As it stands, I'm not sure how to do this. Once I add "using ContinuousLinq", all of my queries go through the Clinq extensions.

Sometimes, I don't want things going through Clinq. One example is when an expression includes a lambda delegate. In this case, Clinq throws an exception indicating that it doesn't support lambdas.

The AsReadOnly extension method could provide the "opt in", allowing me to control which queries should be continuous and which should be standard queries.

If the ObservableCollection extensions were removed, then users would need to add AsReadonly() to a query to get it to use CLINQ. If the extensions were moved to a separate namespace, then the user could still get the "automatic" behavior by including another using statement like "using ContinuousLinq.Auto" or something like that.

Are there downsides or dangers to such a change? Maybe I'm missing something that resulted in the current design decisions.

Thanks.