Laden...

Forenbeiträge von mec Ingesamt 19 Beiträge

02.02.2015 - 07:34 Uhr

So ganz auf Herz und Nieren habe ich sie natürlich nicht getestet. Mein Focus lag auf der Remove-Problematik. Ansonsten (Browsen, Add) hat sie aber eigentlich einwandfrei funktioniert.

Es muss irgendwie mit der internen Kopie der Liste und dem Aufruf von RemoveCurrent() zusammenhängen ...

23.01.2015 - 17:13 Uhr

Meiner Meinung nach geht das nicht in einem Schritt. Du willst dem Deserialisierer als Parameter mitgeben, wo er anfangen soll. Richtig?

Das wird wohl nix. Du musst Dich mit einem XmlReader durchtasten bis zu der Ebene, von der aus Du verarbeiten willst. Und musst noch abfragen, wann sie zu Ende ist.

Das Problem kenn ich gut von XML-Dateien, die SAP exportiert. Da muss man auch zu Fuß immer zu <item> runter ...

23.01.2015 - 16:49 Uhr

Die BindingSource manipuliert die als DataSource übergebene Liste nur bei Änderungen, Inserts (Adds) und Deletes (Remove).
Intern muss sie aber eine eigene Liste mit Verweis auf die originalen Elemente führen. Das kann nur so sein, denn sonst würden Sort und Filter nicht funktionieren ohne die originale Liste zu verändern.

Das erklärt aber leider immer noch nicht, warum meine Implementation von IList nicht funktioniert ...

23.01.2015 - 16:37 Uhr

Oh Mann, da möchte ich dann aber auch den tatsächlichen Anwendungsfall mal bitte erfahren.

Es ist aber nix anderes als vorher. Nur mit einem Nested und einer Gruppierung mehr:


select
	 tbl.ID
	,tbl.SpA
	,tbl.SpB
	,tbl.Zugriff
from
	(
		select
			 SpA
			,min(Zugriff) as MinSpA
		from
			Table_1
		group by
			SpA
	) spa
	inner join
	(
		select
			 SpA
			,SpB
			,min(Zugriff) as MinSpB
		from
			Table_1
		group by
			 SpA
			,SpB
	) spb on
		spa.SpA = spb.SpA
	inner join Table_1 tbl on
		spb.SpA = tbl.SpA
		and
		spb.SpB = tbl.SpB
order by
	 MinSpA
	,MinSpB
	

Mal so als Tipp (keine Kritik oder Vorwurf):

Wenn Du die Problemstellung für Dich selbst (und somit natürlich auch für andere) klar formulierst, hast Du bereits die halbe Lösung.

Der erste Fall:

Die Sortierung ist nicht (wie Du eingangs geschrieben hast) Zugriff -> SpA -> Zugriff, sondern SpA -> Zugriff. Wobei SpA nicht seiner natürlichen Sortierordnung (also Alphabet oder Collation) unterliegt, sondern einer Abhängigkeit von Zugriff innerhalb seiner Gruppe. Wenn Du das so formulierst, ergibt sich der erste Teil-SQL schon fast von selbst.

Der zweite Fall:

SpA bildet eine eigene Gruppe, die nach dem ältesten Zugriff sortiert werden soll. Innerhalb dieser Gruppe bildet SpB Untergruppen, die nach dem gleichen
Schema sortiert werden sollen. Allerdings innerhalb der SpA-Gruppe, was es erforderlich macht, SpA im Group by zu berücksichtigen.
Und zu diesen Sortierungen muss ich mir dann nur noch die restlichen Daten (ID und Zugriff) aus der Tabelle holen und die order by Klausel anwenden.

So, das war SQL in Prosa. Aber die Parallelen springen doch förmlich ins Auge, oder?

Mit der Linq-Syntax stehe ich leider auf Kriegsfuss, aber das wirst Du schon hinkriegen.

So. Und wofür brauchst Du das jetzt?

23.01.2015 - 07:49 Uhr

Jetzt dämmert es - glaube ich:

Die Sortierung nach SpA erfolt nach dem Kriterium, welche SpA das kleinste Datum hat d.h. das kleinste Datum innerhalb der SpA-Gruppe bestimmt die Reihenfolge der der SpA-Sortierung, richtig? Und dann ist das auch schon die Lösung: Group by und ein geschachtelter Select:

Zunächst musst Du die Sortierordnung für SpA ermitteln. Das geht so:

select
	 SpA
	,min(Zugriff) as MinZugriff
from
	[dbo].[Table_1]
group by
	SpA

Das ist jetzt noch nicht sortiert, muss es an dieser Stelle aber noch nicht, denn wir sind ja noch nicht fertig.

Dieses Ergebnis musst Du nun noch mit den restlichen Datensätzen joinen:


select
	 t.ID
	,t.SpA
	,t.Zugriff
from
(
select
	 SpA
	,min(Zugriff) as MinZugriff
from
	[dbo].[Table_1]
group by
	SpA
) m
inner join [dbo].[Table_1] t on
	m.SpA = t.SpA
order by
	 MinZugriff
	,t.SpA
	,Zugriff

Et voila ..

22.01.2015 - 23:49 Uhr

Sorry, aber das verstehe ich nicht ganz. Dann ist die Sortierordnung doch einfach SpA und dann Zugriff.

Wie soll sich denn eine Sortierung von Zugriff an dritter Stelle auswirken, wenn schon an erster Stelle in der Sortierordnung stand?

Dein Beispiel spiegelt das auch nicht wider. Denn wäre nach Zugriff zuerst sortiert, könnte nach dem 01.01.2002 in der dritten Zeile nicht der 01.01.2000 in der vierten folgen ...

22.01.2015 - 23:37 Uhr

verwendetes Datenbanksystem: ADO.NET

Nach langem Stöbern im Netz habe ich unzählige Abhandlungen über die Verknüpfung zweier BindingSources für Master-Detail-Anforderungen gefunden.
Wie sieht es aber umgekehrt aus, wenn ich zu meinen Details die Master-Daten haben möchte? Also ein Foreign Key Join.

Oder anders ausgedrückt: wenn wir bei der berühmten Northwind bleiben, möchte ich mich primär durch eine Liste aller Orders bewegen und in einem Detailbereich Informationen zu Customer (Name, Adresse etc) und zu Products anzeigen. Also zwei Joins auf zwei Master-Tabellen.

Geht das überhaupt mit verknüpften BindingSources (wo eine die DataSource für die andere ist) oder muss ich hier mit der Filter-Eigenschaft arbeiten, indem ich sie für die Master-BS anpasse, wenn sich die Detail-BS ändert oder bewegt?

Bei berechneten Columns kann ich in der Expression ja die Parent-Row referenzieren, aber bei BindingSource habe ich bisher immer nur Beispiele für die Verknüpfung mit den Child-Rows finden können (also von Products auf Orders oder von Customer auf Orders).

Die entsprechenden Relationen legt der DataSet-Designer zwar an. Aber wenn ich meine Detail-BS (Orders) als DataSource für meine Master-BS (Customer) zuweise, wird mir die entsprechende Relation für DataMember nicht angeboten. Mache ich es umgekehrt bekomme ich wieder Master-Detail statt dem gewünschten Detail-Master ...

20.01.2015 - 09:53 Uhr

So! Mit dem Überschreiben der virtuellen Methoden und dem AddingNew-Event in BindingList<T> funktioniert es.

Aber eines verstehe ich immer noch nicht: Warum hat meine Implementation von IList (siehe Beitrag weiter oben) nicht funktioniert?

Kannst Du mir das vielleicht erklären, Sebastian?

Vielen Dank !!!

18.01.2015 - 15:16 Uhr

Wow, das sieht wirklich gut aus. Dass die Remove-Methode hier virtuell ist hatte ich übersehen (Asche auf mein Haupt !!!) und vielen Dank. Dann war Sebastians Tipp doch der Richtige.

Ich werde das jetzt ausgiebig testen und dann denn Thread schließen - falls nicht noch neue Probleme auftreten.

Vielen Dank an alle!

Achim

18.01.2015 - 14:13 Uhr

BindingList<T> habe ich jetzt auch probiert. Die Klasse stellt mir exakt die gleichen Eigenschaften, Methoden und Events zur Verfügung wie BindingSource selbst. Das Problem ist aber, dass ich keinen Zugriff auf das gelöschte oder zu löschende Element habe. ListChangedEventArgs gibt mir zwar die Information, dass gelöscht wurde, jedoch keine Referenz mehr auf das gelöschte Objekt. Und genau das muss ich aber behandeln. Da es sich bei meinen Elementen um DataRows oder abgeleitete typisierte Klassen handelt, muss ich deren RowState auch auf Deleted setzen können. DataTable oder TypedDataTable können das ja auch. Die kann ich aber nicht verwenden, weil Sie nur ihre Columns zur Bindung bereitstellen (der vorherige Post).

Ich habe sogar schon versucht, berechnete Spalten hinzuzufügen, aber da bietet die Expression einfach nicht genügend Möglichkeiten.

18.01.2015 - 11:13 Uhr

Hallo Sebastian,

etwas in der Art habe ich auch schon vermutet und deshalb eine eigene IList-Klasse implementiert. Aber ganz verstehe ich es dennoch nicht. Die Eigenschaft List der BindingSource ist doch eine IList-Schnittstelle und sollte sich dann doch auch deren Remove-Methoden bedienen. Aber ich werde das mit der Implementierung von BindingList<T> auf alle Fälle probieren.

Der Vollständigkeit halber aber hier nochmals meine Implementation von IList. Hier findet keine Redefinition der Remove-Methoden statt.
Kann es auch sein, dass die BindingSource gar nicht mit dem Objekt selbst sondern mit dessen Enumerator arbeitet?

using System;
using System.Collections;
using System.Collections.Generic;
using System.Text;

namespace Test
{
    class RowList<T> : IList<T>
    {
        private List<T> list = new List<T>();




        public void Add(T item)
        {
            this.list.Add(item);
        }


        public bool Contains(T item)
        {
            return this.list.Contains(item);
        }


        public void Clear()
        {
            this.list.Clear();
        }


        public void CopyTo(T[] array, int arrayIndex)
        {
            this.list.CopyTo(array, arrayIndex);
        }


        public int Count
        {
            get { return this.list.Count; }
        }


        public bool IsReadOnly
        {
            get { return false; }
        }


        public bool Remove(T item)
        {
            return this.list.Remove(item);
        }


        public void RemoveAt(int index)
        {
            this.list.RemoveAt(index);
        }


        public int IndexOf(T item)
        {
            return this.list.IndexOf(item);
        }


        public void Insert(int index, T item)
        {
            this.list.Insert(index, item);
        }


        public T this[int index]
        {
            get { return this.list[index]; }
            set { this.list[index] = value; }
        }


        public IEnumerator<T> GetEnumerator()
        {
            //return new RowEnumerator<T>(this);
            //return this.list.GetEnumerator();
            return this.list as IEnumerator<T>;
        }


        IEnumerator IEnumerable.GetEnumerator()
        {
            //return new RowEnumerator<T>(this);
            //return this.list.GetEnumerator();
            return this.list as IEnumerator<T>;
        }
        


        class RowEnumerator<T> : IEnumerator<T>
        {
            private RowList<T> _List;
            private int _Index = -1;
            private T _Current;

            public RowEnumerator(RowList<T> list)
            {
                this._List = list;
                this._Index = -1;
                this._Current = default(T);
            }


            public bool MoveNext()
            {
                if (++this._Index >= this._List.Count)
                    return false;

                this._Current = this._List[this._Index];

                return true;
            }


            public void Reset()
            {
                this._Index = -1;
            }


            public T Current
            {
                get { return this._Current; }
            }


            object IEnumerator.Current
            {
                get { return this._Current; }
            }

            void IDisposable.Dispose() { }
        }
    }
}

17.01.2015 - 21:17 Uhr

verwendetes Datenbanksystem: keines - nur DataSet

Da ich in meinem vorangegangenen Post "Selbstdefinierte Properties in typisierter DataRow können nicht gebunden werden" leider zu keiner Lösung gekommen bin, habe ich einen anderen Weg probiert, indem ich meine DataRows in einer eigenen generischen Liste selbst verwalte, die ich dann der BindingSource als DataSource übergebe. Das setzt jedoch voraus, dass ich besonders die Löschmethoden meiner Liste gesondert behandele.

Nun hat sich aber gezeigt, dass ich die Remove-Methoden meiner Liste nicht abfangen kann, weil sie von der BindingSource gar nicht aufgerufen werden:

using System;
using System.Collections.Generic;
using System.Windows.Forms;

namespace Test
{
    static class Program
    {
        /// <summary>
        /// Der Haupteinstiegspunkt für die Anwendung.
        /// </summary>
        [STAThread]
        static void Main()
        {
            Application.EnableVisualStyles();
            Application.SetCompatibleTextRenderingDefault(false);
            Application.Run(new FormTest());
        }
    }

    public class FormTest : Form
    {
        public FormTest()
        {
            BindingSource bindingSource = new BindingSource();
            bindingSource.DataSource = new ItemList();

            BindingNavigator bindingNavigator = new BindingNavigator(bindingSource);

            DataGridView dataGridView = new DataGridView();
            dataGridView.DataSource = bindingSource;
            dataGridView.Dock = DockStyle.Fill;

            this.Controls.AddRange(new Control[] { bindingNavigator, dataGridView });
        }
    }


    class Item
    {
        public int Id { get; private set; }

        public string Name { get; private set; }


        public Item(int id, string name)
        {
            this.Id = id;
            this.Name = name;
        }
    }


    class ItemList : List<Item>
    {
        public ItemList() : base()
        {
            for (int i = 1; i <= 15; i++)
                this.Add(new Item(i, string.Format("Item {0}", i)));
        }


        new public bool Remove(Item item)
        {
            return base.Remove(item);
        }


        new public void RemoveAt(int index)
        {
            base.RemoveAt(index);
        }
    }


}

Setze ich nun Haltepunkte in meinen redefinierten Remove-Methoden, so werden diese gar nicht angelaufen, wenn ich im DatgridView oder mit dem Remove-Button auf dem BindingNavigator Datensätze lösche. Dennoch wir meine Liste entsprechend verändert.

Aber welcher Methoden bedient sich die BindingSource zum Löschen eigentlich?

Der gleiche Effekt tritt übrigens auch ein, wenn ich meine Liste als komplett eigene IList<T>-Klasse implementiere.

09.01.2015 - 15:55 Uhr

Leider habe ich nichts gefunden, was die Eigenschaft Columns zur präferierten Binding-Eigenschaft macht - oder eben nicht, sondern eine andere nämlich die Struktur der DataRow.

Ich vermute eher, das geschieht schon vorher irgendwo in der Vererbungshierarchie zwischen DataTable und der TypedTableBase<T>-Klasse.

Und genau da beim Enumerator liegt vermutlich des Rätsels Lösung:


namespace System.Data
{
    // Zusammenfassung:
    //     Dieser Typ wird als Basisklasse für die typisierte System.Data.DataTable-Objektgenerierung
    //     durch Visual Studio und das .NET Framework-Tool XSD.exe verwendet, und er
    //     ist nicht für die direkte Verwendung im Code vorgesehen.
    //
    // Typparameter:
    //   T:
    //     Der Typ der Objekte in der von der Tabelle dargestellten Quellsequenz, meist
    //     System.Data.DataRow.
    [Serializable]
    public abstract class TypedTableBase<T> : DataTable, IEnumerable<T>, IEnumerable where T : System.Data.DataRow
    {
        // Zusammenfassung:
        //     Initialisiert eine neue System.Data.TypedTableBase'1.Diese Methode unterstützt
        //     die typisierte System.Data.DataTable-Objektgenerierung durch Visual Studio
        //     und das .NET Framework-Tool XSD.exe.Dieser Typ ist nicht für die direkte
        //     Verwendung im Code vorgesehen.
        [TargetedPatchingOptOut("Performance critical to inline this type of method across NGen image boundaries")]
        protected TypedTableBase();
        //
        // Zusammenfassung:
        //     Initialisiert eine neue System.Data.TypedTableBase'1.Diese Methode unterstützt
        //     die typisierte System.Data.DataTable-Objektgenerierung durch Visual Studio
        //     und das .NET Framework-Tool XSD.exe.Diese Methode ist nicht für die direkte
        //     Verwendung im Code vorgesehen.
        //
        // Parameter:
        //   info:
        //     Eine System.Runtime.Serialization.SerializationInfo, die Daten zum Erstellen
        //     des Objekts enthält.
        //
        //   context:
        //     Der Streamingkontext für das deserialisierte Objekt.
        [TargetedPatchingOptOut("Performance critical to inline this type of method across NGen image boundaries")]
        protected TypedTableBase(SerializationInfo info, StreamingContext context);

        // Zusammenfassung:
        //     Konvertiert die Elemente einer System.Data.TypedTableBase'1 in den angegebenen
        //     Typ.Diese Methode unterstützt die typisierte System.Data.DataTable-Objektgenerierung
        //     durch Visual Studio und das .NET Framework-Tool XSD.exe.Diese Methode ist
        //     nicht für die direkte Verwendung im Code vorgesehen.
        //
        // Typparameter:
        //   TResult:
        //
        // Rückgabewerte:
        //     Eine System.Data.EnumerableRowCollection, die jedes Element der Quellsequenz
        //     enthält, das in den angegebenen Typ konvertiert wird.
        public EnumerableRowCollection<TResult> Cast<TResult>();
        //
        // Zusammenfassung:
        //     Gibt einen Enumerator für die typisierte System.Data.DataRow zurück.Diese
        //     Methode unterstützt die typisierte System.Data.DataTable-Objektgenerierung
        //     durch Visual Studio und das .NET Framework-Tool XSD.exe.Diese Methode ist
        //     nicht für die direkte Verwendung im Code vorgesehen.
        //
        // Rückgabewerte:
        //     Ein Objekt, das die System.Collections.Generic.IEnumerator<T>-Schnittstelle
        //     implementiert.
        public IEnumerator<T> GetEnumerator();
    }
}

Ich hatte gehofft, dass jemand weiß, wie und wo man da ansetzen kann, aber das scheint nicht gerade trivial zu sein.

Mein Projekt hat sehr komplexe in sich verschachtelte Objekt-Strukturen, die sich gegenseitig referenzieren. Und damit eine Änderung in einem der Objekte sich auch tatsächlich überall durchzieht, möchte ich nicht mit Kopien dieser Objekt arbeiten. Daher war meine Idee, die Rows der einzelnen Tabellen, die in Dritter Normalform vorliegen, direkt über Interfaces verbinden. Das DataSet soll eigentlich nur einen Daten-Container darstellen und eine bequeme Verbindung zu austauschbaren Datenbankplattformen herstellen (Multi Layer Modell).

Das wäre halt eine elegante Lösung gewesen, wenn die BindingSource da mitspielen würde.

Dann muss ich halt doch die Daten aus der Datenbank lesen, in die Objektstruktur kopieren und anschließend wieder wegschreiben.
Dann kann ich leider nicht die DataTable als zu bindendes List-Objekt für die BindingSource verwenden, sondern muss die Rows in einer eigenen Liste verwalten, um den erforderlichen und auch so praktischen RowState (inserted, deleted, modified etc) für das DB-Update verwenden zu können.

Aber es wäre halt so viel einfacher, wenn ich die an die BindingSource zu bindende Eigenschaft der zugrundeliegenden DataTable einfach redefinieren oder überschreiben könnte ... da war wohl der Wunsch Vater des Gedanken ...

09.01.2015 - 12:40 Uhr

Hier ist meine partielle Klasse:


using System;

namespace Test 
{
    public interface IMy
    {
        Guid Id { get; }

        string Name { get; set; }

        byte[] Logo { get; set; }
    }

    
    public partial class MyDataSet 
    {
        partial class MYRow : IMy
        {
            public Guid Id
            {
                get { return this.CON_ID; }
            }
            

            public string Name
            {
                get
                {
                    try { return this.CON_NAME; }
                    catch { return null; }
                }

                set
                {
                    if (string.IsNullOrWhiteSpace(value))
                        this.SetCON_NAMENull();
                    else
                        this.CON_NAME = value.Trim();
                }
            }


            public byte[] Logo
            {
                get
                {
                    try { return this.CON_LOGO; }
                    catch { return null; }
                }

                set
                {
                    if (value == null || value.Length == 0)
                        this.SetCON_LOGONull();
                    else
                        this.CON_LOGO = value;
                }

            }
        }

    }
}


Und das ist der Designer-Code von der Row:


       
        /// <summary>
        ///Represents strongly named DataRow class.
        ///</summary>
        public partial class MYRow : global::System.Data.DataRow {
            
            private MYDataTable tableMY;
            
            [global::System.Diagnostics.DebuggerNonUserCodeAttribute()]
            [global::System.CodeDom.Compiler.GeneratedCodeAttribute("System.Data.Design.TypedDataSetGenerator", "4.0.0.0")]
            internal MYRow(global::System.Data.DataRowBuilder rb) : 
                    base(rb) {
                this.tableMY = ((MYDataTable)(this.Table));
            }
            
            [global::System.Diagnostics.DebuggerNonUserCodeAttribute()]
            [global::System.CodeDom.Compiler.GeneratedCodeAttribute("System.Data.Design.TypedDataSetGenerator", "4.0.0.0")]
            public System.Guid CON_ID {
                get {
                    return ((global::System.Guid)(this[this.tableMY.CON_IDColumn]));
                }
                set {
                    this[this.tableMY.CON_IDColumn] = value;
                }
            }
            
            [global::System.Diagnostics.DebuggerNonUserCodeAttribute()]
            [global::System.CodeDom.Compiler.GeneratedCodeAttribute("System.Data.Design.TypedDataSetGenerator", "4.0.0.0")]
            public string CON_NAME {
                get {
                    try {
                        return ((string)(this[this.tableMY.CON_NAMEColumn]));
                    }
                    catch (global::System.InvalidCastException e) {
                        throw new global::System.Data.StrongTypingException("Der Wert für Spalte CON_NAME in Tabelle MY ist DBNull.", e);
                    }
                }
                set {
                    this[this.tableMY.CON_NAMEColumn] = value;
                }
            }
            
            [global::System.Diagnostics.DebuggerNonUserCodeAttribute()]
            [global::System.CodeDom.Compiler.GeneratedCodeAttribute("System.Data.Design.TypedDataSetGenerator", "4.0.0.0")]
            public byte[] CON_LOGO {
                get {
                    try {
                        return ((byte[])(this[this.tableMY.CON_LOGOColumn]));
                    }
                    catch (global::System.InvalidCastException e) {
                        throw new global::System.Data.StrongTypingException("Der Wert für Spalte CON_LOGO in Tabelle MY ist DBNull.", e);
                    }
                }
                set {
                    this[this.tableMY.CON_LOGOColumn] = value;
                }
            }
            
            [global::System.Diagnostics.DebuggerNonUserCodeAttribute()]
            [global::System.CodeDom.Compiler.GeneratedCodeAttribute("System.Data.Design.TypedDataSetGenerator", "4.0.0.0")]
            public bool IsCON_NAMENull() {
                return this.IsNull(this.tableMY.CON_NAMEColumn);
            }
            
            [global::System.Diagnostics.DebuggerNonUserCodeAttribute()]
            [global::System.CodeDom.Compiler.GeneratedCodeAttribute("System.Data.Design.TypedDataSetGenerator", "4.0.0.0")]
            public void SetCON_NAMENull() {
                this[this.tableMY.CON_NAMEColumn] = global::System.Convert.DBNull;
            }
            
            [global::System.Diagnostics.DebuggerNonUserCodeAttribute()]
            [global::System.CodeDom.Compiler.GeneratedCodeAttribute("System.Data.Design.TypedDataSetGenerator", "4.0.0.0")]
            public bool IsCON_LOGONull() {
                return this.IsNull(this.tableMY.CON_LOGOColumn);
            }
            
            [global::System.Diagnostics.DebuggerNonUserCodeAttribute()]
            [global::System.CodeDom.Compiler.GeneratedCodeAttribute("System.Data.Design.TypedDataSetGenerator", "4.0.0.0")]
            public void SetCON_LOGONull() {
                this[this.tableMY.CON_LOGOColumn] = global::System.Convert.DBNull;
            }
        }


Da ist eigentlich alles Standard. Und das Problem liegt sicher auch nicht an dieser Stelle. Vielmehr kann die BindingSource nicht auf die neuen Properties zugreifen. Vermutlich greift diese einfach nur auf Table.Columns zu ..

09.01.2015 - 10:54 Uhr

Ja, das ist alles richtig. In meiner partiellen Klasse habe ich auch Zugriff auf die vom Designer generierten Eigenschaften und Methoden.

Der Object-Browser zeigt mir allerdings weder meine noch die vom Designer generierten Eigenschaften an. Aber das ist eigentlich normal. Der zeigt nur Typdefinitionen an aber keine Properties.

Nee, so einfach isses leider nicht ...

09.01.2015 - 10:29 Uhr

verwendetes Datenbanksystem: SQL-Server, Access

Hallo,

ich habe ein typisiertes DataSet mit einer entsprechend typisierten DataTable (MYDataTable) und DataRow (MYRow) von Designer generieren lassen.

Die MYRow habe ich nun in einer eigenen Datei als partielle Klasse um public Properties erweitert. Wenn ich MYDataTable nun an die DataSource einer Forms.BindingSource übergebe, kann ich diese neuen Properties nicht binden. Weder im Designer noch zur Laufzeit.

Warum ist das so?

Kann es sein, dass nur die Columns-Eigenschaft des Table-Objekts gebunden werden kann?

Gibt es ein Attribut, welches mir diese neuen Properties zur Bindung bereit stellt ("[Bindable(true)]" tut es leider nicht)?

Vermutlich trifft meine erste Vermutung zu. Aber kann man das ändern?

Vielen Dank vorab.

10.03.2014 - 09:40 Uhr

Hallo Mr. Skywalker,

vielen Dank. Das (der erste) ist genau das, was ich gesucht habe. Es ist halt nicht immer ganz einfach, die richtigen Suchbegriffe zu finden.

Beste Grüsse

09.03.2014 - 19:03 Uhr

Hallo Scavanger,

vielen Dank für den Link. Den werde ich jetzt mal verfolgen, obwohl das Wort "Rippen" für mich so einen illegalen Anklang hat und es mir ja um meine eigenen CDs geht. Dafür vielen Dank.

Ich selbst komme weniger aus der schwedschen Metal-Fraktion, sondern bin mit fast 50 Jahren eher im old school Blues-Rock zuhause. Entsprechend lange bin ich auch schon in meinem Beruf tätig und nicht zum ersten Mal in einem Forum unterwegs. Natürlich habe ich im diesem auch gesucht, aber das war leider ergebnislos, sonst hätte ich nicht gepostet. Wenn Du einen entsprechenden Beitrag im Forum kennst, wäre ich für einen entsprechenden Link natürlich sehr dankbar.

Auch den Punkt 1.1 habe ich gelesen. Dennoch vielen Dank für den Hinweis. Ich lasse mich gerne belehren ...

09.03.2014 - 13:45 Uhr

Hallo,

kennt jemand eine Möglichkeit, Audio-CDs direkt als wav-Dateien aus C# heraus zu importieren. Ich weiss, dass es hierzu viele Möglichkeiten und Tools gibt, aber ich möchte mir diesen Schritt sparen, um die Daten dirket in einer eigenen Anwendung weiter verarbeiten zu können.

Viele Dank vorab.