Willst du ein generisches Interface in einer Liste benutzen, musst du das Interface splitten in ein Generisches und ein Nicht-Generisches Interface.
Also wird aus:
interface IDataSource<TSource>
{
TSource GetCurrentDatabase();
void CreateNewDatabase();
TSource[] GetQuerySources(DateTime from, DateTime to);
}
das hier
interface IDataSource
{
void CreateNewDatabase();
}
interface IDataSource<TSource> : IDataSource
{
TSource GetCurrentDatabase();
TSource[] GetQuerySources(DateTime from, DateTime to);
}
in deinem Fall sollte es aber reichen wenn du den DataSourceManager Generisch machst. Vielleicht wär hier sogar ein Singleton angebracht, weiss aber gerade nicht in wie fern die Instanz benutzt wird.
jo - der link scheint gut zu sein - habs grad nur ueberflogen
was mir dort wieder aufgefallen ist diese generische AttachedBehavior "funktionalitaet"
sowas hab ich auch , aber in einer abgespeckten version - bei der publizierten generischen version gefaellt mir nicht das nur die CommandParameter uebergeben werden - nicht die eigentlichen event parameter
so kann man es zb fuer Closing e.Cancel = true nicht verwenden , da man gar keine entsprechenden parameter bekommt
ich wollte mir auch schon eine generische loesung ausdenken - bin aber noch nicht dazu gekommen - mir sind da nur zwei sachen wichtig - einmal das man auch kurz schreiben kann - und zum anderen das man die event parameter (evtl optional) bekommt
wie gesagt - versuch ich spaeter mal
genau das DelegateCommand
das hab ich auch - klar - hat man bei mvvm eh
nur da hab ich ebenso eine kuerzere version - in dem link ist ein beispiel mit DelegateCommand wo ich bisher kein mehrwert erkennen konnte - viele objekte die man - soweit ich das seh - gar nicht brauch
aber wie gesagt - der link scheint gut zu sein {=
auch dann wuerd ich sagen => design fehler
CreateNewList sortiert nur die parameter list ?
eine sortierte liste ist doch keine neue liste
dann ist entweder
List.Sort zu verwenden oder
SortList(List) zu erstellen
am sonsten - irgendwo
listRef = toUseList;
zu schreiben duerfte doch eigentlich kein problem sein
Ich habe jetzt mal versucht garnichts zu machen , dh. die
DataError Methode leer zu lassen. Dann erhalte ich keine Fehlermeldung
jedoch sind die einzelnen Textfelder welche ich über
tb_Vorname.DataBindings.Add("Text", bindingSource1, "Vorname");
etc
anbinde, nicht mehr mit dem Gridview verbunden und zeigen nichts an.
dasonmos schrieb:
Lies dir einfach mal die betreffenden Abschnitte hier drin durch. Ist recht umfangreich, als Einsteigerlektüre oder um einen umfassenderen Wissenstand zu erhalten hilfreich: http://www-alt.uni-trier.de/urt/user/baltes/docs/csharp/csharp.htm
Das Dokument enthält weniger Informationen über die C# Netzwerkprogrammierung als die von mir zitierte Quelle.
dasonmos schrieb:
Nur mal so als Ansatz. Vielleicht liegt es auch ganz einfach an deinem Client. Ich würde empfehlen, dass du dir selbst einen schreibst (der natürlich auf einem anderen Port läuft) und einfach mal schaust was passiert. Ich weiß zwar nicht wirklich wie es mit Putty aussieht, aber das verwendet doch SSH und andere Protokolle. Dein Server verwendet aber schleicht und einfach TCP. Das ist eine ganz andere Ebene im OSI-Layer.
Irgendwie hab ich das Gefühl du verstehst das OSI-Modell nicht. Auch PuTTY verwendet natürlich TCP. Praktisch jede Anwendung im Internet nutzt entweder UDP oder TCP als Transportprotokoll für die Daten. Das SSH Protokoll basiert auf der Transportschicht TCP. Das SSH ist ein Protokoll der Anwendungsschicht, was auf Sicherheit ausgelegt ist. Auch das HTTP befindet sich in der Anwendungsschicht und nutzt ebenfalls TCP.
Natürlich kann man sich mit PuTTY zu einem TCP Server geschrieben in C# verbinden. Man muss nur den richtigen Port unter localhost wählen.
Alter Falter schrieb:
Und wo ist das Problem? Einen Zugriffsmodifizierer muss der Konstruktor doch sowieso haben, wenn er nicht private sein soll. Also ist das doch keine Mehrarbeit.
Es geht nicht um Mehrarbeit, es geht um Klarheit. Mit abstract kann ich deutlich die komplette Klasse als abstrakt deklarieren ohne explizit mir Gedanken um die Konstruktoren zu machen.
Alter Falter schrieb:
Viel komischer finde ich es, wieso ich in einer als abstract markierten Klasse den Konstruktor trotzdem noch auf public oder protected setzen kann. Wo ist da der Sinn? Was ist der Unterschied zwischen
abstract class X
{
public X() { }
}
und
abstract class X
{
protected X() { }
}
?
In C# ist der Default-Konstruktor auch automatisch immer protected, sobald die Klasse abstract ist. In vielen Fällen wird nämlich überhaupt kein Konstruktor implementiert.
Falls ein Konstruktor implementiert wird um Initialisierungen etc. vorzunehmen, dann ist es sogar ein guter Codestil, den Konstruktor einer abstrakten Klasse zusätzlich mit protected zu versehen, weil es zeigt das nur die abgeleitete Klasse sie instanzieren kann. Natürlich macht es dann keinen Sinn den Konstruktor auf public zu stellen.
Habe nun ein kleines Programm welches mir alle Fenster eines Prozesses zeigt.
Bei VFP 9 zeigt er kein einges Handle auf ein Fenster an. ENUMWINDOWS wurde verwendet.
Jemand eine Ahnung?
Dasonomos schrieb:
Ich hätte es eigentlich zuerst mal mit der GDI verwendet. Sowas wie DrawRectangle() und auf die richtige Größe gezeichnet.
Reicht für ein simples Balkendiagramm definitiv aus, ist exportierbar als Image und relativ leicht umzusetzen. Und mit etwas Gewöhnung kann man damit auch komplexe Funktionen zeichenn lassen.
mache es jetzt auch mit der GDI ... und dem rectangle...
das Coordinatensystem kann ich ja noch einzeln daneben erstellen dank GDI
reicht für mein Projekt auch aus
Danke euch
ok
man kann ja eigentlich nichts falsch machen - solang es klar lesbar ist und gut wartbar ist es gut - "professionell" hin oder her #gg
ma gugg
ich hatte das glaub ich ziemlich uebernommen von der msdn da ich genau so auch brauchte #gg
<Window.Resources>
<!-- ToDo: move the CollectionViewSource to the ListBox direct -->
<CollectionViewSource x:Key="UserSource" Source="{Binding Path=Users}">
<CollectionViewSource.GroupDescriptions>
<PropertyGroupDescription PropertyName="Mode" />
</CollectionViewSource.GroupDescriptions>
<CollectionViewSource.SortDescriptions>
<scm:SortDescription PropertyName="Name" Direction="Ascending" />
</CollectionViewSource.SortDescriptions>
</CollectionViewSource>
</Window.Resources>
.
.
.
<ListBox ItemsSource="{Binding Source={StaticResource UserSource}}" SelectedItem="{Binding CurrentUser}">
<ListBox.GroupStyle>
<GroupStyle>
<GroupStyle.ContainerStyle>
<Style TargetType="{x:Type GroupItem}">
<Setter Property="Margin" Value="0,0,0,5"/>
<Setter Property="Template">
<Setter.Value>
<ControlTemplate TargetType="{x:Type GroupItem}">
<Expander IsExpanded="True">
<Expander.Header>
<DockPanel>
<TextBlock FontWeight="Bold" Text="{Binding Path=Name}" Margin="5,0,10,0" />
<TextBlock FontWeight="Bold" Text="{Binding Path=ItemCount}"/>
</DockPanel>
</Expander.Header>
<Expander.Content>
<ItemsPresenter />
</Expander.Content>
</Expander>
</ControlTemplate>
</Setter.Value>
</Setter>
</Style>
</GroupStyle.ContainerStyle>
</GroupStyle>
</ListBox.GroupStyle>
</ListBox>
ich hab noch auf meiner todo stehen die collectionviewsources von den resourcen direkt in die liste zu packen , hatte bei der erstem implementation keine zeit das ich es schnell zusammen geschustert hatte {hab das ToDo: mark aber eben erst wieder gefunden #gg}
ich mags nicht sowas unnoetig auseinander zu ziehen {weil man es nur an einer stelle braucht}
btw , die namen user und mode sieht zwar sehr nach demo aus , aber ich hab wirklich eine user liste #gg
so - jetzt erstma arbeits musik ein schalten - muss noch was schaffen {=
http://www.youtube.com/watch?v=85mLq4vH_mc
http://www.youtube.com/watch?v=P84eAzdmHkw
Ich hoffe ich bin noch nicht zu spät.
Den Benutzer, der das Programm ausführt, kannst du mit Environment.UserName ermitteln:
http://msdn.microsoft.com/de-de/library/system.environment.username.aspx
Das heißt dein Programm dürfte dann nicht als Dienst vom System, sondern vom User selbst im Autostart ohne Form gestartet werden. Die Benutzerrechte bkommst du so bestimmt irgendwie über die Konsole raus.
Die andere Möglichkeit schaut aus wie folgt:
WindowsIdentity id = WindowsIdentity.GetCurrent();
WindowsPrincipal p = new WindowsPrincipal(id);
bool isAdmin = p.IsInRole(WindowsBuiltInRole.Administrator);
Du musst nur noch eventuelle Exceptions per catch abfangen und/oder isAdmin zurückgeben.
