Hi!
Hilfreich wären ein paar mehr Informationen...
Machst du den Zugriff mit ADO.NET? Also C# oder was verwendest du. Welche Plattform (Windows, Linux, ...)?
MfG
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace Passwort1
{
class Program
{
static void Main(string[] args)
{
string x, u, v, w;
int passworteins, passwortzwei, passwortdrei, passwortvier;
int eingabeeins, eingabezwei, eingabedrei, eingabevier;
int eingabeende, passwortende;
int durchgang = 0;
passworteins = Convert.ToChar('B');
passwortzwei = Convert.ToChar('K');
passwortdrei = Convert.ToChar('F');
passwortvier = Convert.ToChar('T');
passwortende = passworteins + passwortzwei + passwortdrei + passwortvier;
do
{
Console.WriteLine(" Bitte geben sie das Passwort ein ");
x = Console.ReadLine();
u = Console.ReadLine();
v = Console.ReadLine();
w = Console.ReadLine();
eingabeeins = Convert.ToInt32(char.ToUpper(Convert.ToChar(x)));
eingabezwei = Convert.ToInt32(char.ToUpper(Convert.ToChar(u)));
eingabedrei = Convert.ToInt32(char.ToUpper(Convert.ToChar(v)));
eingabevier = Convert.ToInt32(char.ToUpper(Convert.ToChar(w)));
eingabeende = eingabeeins + eingabezwei + eingabedrei + eingabevier;
durchgang++;
}
while (durchgang <= 2 && eingabeende != passwortende);
if(durchgang>2)
Console.WriteLine(" Sie haben zu viele versuche gebraucht");
else Console.WriteLine(" Ihre eingabe ist richtig");
Console.ReadLine();
}
}
}
Es klappt eigentlich...aber wenn der benutzer ddop usw. eingibt zeigt er login richtig....das haengt davon ab weil die werte bkft den wert 423 hat und ddop auch(siehe ascii code)....ich weiss nicht wie man den fehler beseitigen kann.
Also: Mein Fehler war die Reihenfolge. Das ist nicht so aufgefallen, weil die einzelnen Anweisungen in verschiedenen Funktionen auftreten. Aber zusammengefasst stand es vorher so da:
MyForm f = new MyForm();
f.DataGridView.Columns.... // irgendwelche Formatanweisungen.. -> Fehler, da falsche Reihenfolge!!!
f.Show();
Das DataGridView wird offenbar erst mit dem Show-Befehl angelegt. Deshalb ganz klar, kam vorher die Meldung, es gibt keine Objekt-Instanz.
Richtig ist:
MyForm f = new MyForm();
f.Show();
f.DataGridView.Columns.... // irgendwelche Formatanweisungen
Ganz einfach, man muss nur drauf kommen...
micheben schrieb:
ok mit dem letzten satz hab ich mich villt ein wenig falsch ausgedrückt. Ich hab wohl informationen gefunden und auch Googel bemüht aber ich hab in keinem der Links die Antwort auf meine zwei Fragen gefunden. Hast du nur "wpf calendar" in Googel eingegeben oder auch mal den ein oder anderen Link angeklickt :)?
Hoffe es erbarmt sich jemand mir villt auch nur ein schubs in die richtige Richtung zu geben.
Mit freundlichen Grüßen
micheben
Selbst zu deinen beiden gestellten Fragen findest du im Internet ne Lösung.
Hallo,
ich möchte gern mit meiner Click-Once Anwendung eine Textdatei weitergeben.
Diese Textdatei soll bei der Installation in einen bestimmten Ordner kopiert werden.
In den Eigenschaften=>Veröffentlichen=>Anwendungsdateien kann man zwar auswählen welche der Anwendungsdateien veröffentlicht werden sollen, aber es ist nicht möglich einen eigenen Verzeichnis anzugeben.
Danke im Voraus
Es geht um eine Klasse (man nenne sie XYZBuilder, XYZFactory oder was auch immer), die aus einer CSV Datei irgendwelche Instanzen irgendwelcher Klassen erzeugt. Jede Zeile, eine Instanz. Dabei kann der Benutzer zur Laufzeit definieren, welche Spalte der CSV Datei welcher Bedeutung hat. Diese "Regel" kann man dann abspeichern und wieder verwenden.
Das ganze habe ich wie gessagt mit Reflection schon recht einfach gelöst. Dachte es geht viellciht ähnlich einfach auch ohne.
Das ganze sieht dann etwa so aus.
personen.csv
Hans,23,Musterstr. 27
Jürgen,65,Schlossalle 1
class Person
{
public string Name{get;set;}
public string Adresse{get;set;}
}
CSVRule rule = new CSVRule().Property("Name").Ignore().Property("Adresse");
CSVBuilder<Person> builder(rule);
List<Person> personen = builder.Build(new StreamReader("personen.csv"));
class CSVBuilder
{
public List<T> Build(TextReader reader)
{
List<T> result = ...
CSVStream csv = new CSVStream(reader);
while(!csv.EndOfStream)
{
List<string> row = csv.NextRow();
T t = new T();
for(int i = 0; i < rule.Count; ++i)
rule[i].Invoke(t, row[i]);
result.Add(t);
}
return result;
}
}
Irgendwie so.. Was ich tatsächlch geschrieben hab, hab ich grad nicht da, aber so ähnlich.
Man kann natürlich noch irgendwelche Klassen dazuerfinden, oder der Person Klasse statische Methoden verpassen, aber ich wollte es einfach halten und die Person Klasse nicht anpassen müssen.
Mach das Disposable am besten doch wieder, dann werden Resourcen auch früher freigegeben.
zb wenn du ein Objekt in einem using erstellst, dann wird das Dispose direkt aufgerufen sobald der Scope verlassen wird. Wenn du dich auf den Finalizer verlässt kann die Resource noch eine ganze weile im Speicher rum liegen bis es freigegeben wird da der Garbage Collector nach eigenen ermessen los legt. Resourcen sollten aber freigegeben werden sobald man sie nicht mehr benötigt.
Ich konstruiere mal ein Beispiel, du hast ein "MyReader" Objekt der eine Handle zu einem Bild auf macht.
foreach (var folder in folders)
{
object folderImage = null;
using (var reader = new MyReader("theImage.png")
folderImage = reader.GetImage();
myList.Add(new Folder(folder, folderImage);
}
Stell dir vor das "MyReader" IDisposable nicht implementiert und die Datei "theImage" liest, da kann es passieren das es dir um die Ohren fliegt da der Garbage Collector erst los läuft sobald er es will.
Falls es nicht knallt hast du dann X Handles offen, und kannst dann Probleme bekommen.
Wenn "MyReader" aber IDisposable implementiert, wird es jedes mal aufgeräumt sobald der using Scope verlassen wird, d.h. du hast da immer nur ein handle zur selben Zeit offen und es kommt nicht zu unerwarteten Fehlern wegen nicht aufgeräumten Resourcen.
Man ruft das IDisposable nur als Sicherheit im Finalizer auf, falls das Dispose() vergessen wurde. Also sobald du mit Resourcen Arbeitest die aufgeräumt werden müssen, solltest du das IDisposable implementieren.
//Dazu
Aber microsoft/msdn betont immer wieder, dass destruktoren schlecht für die performance sind. so ganz kann ich das nicht nachvollziehen
Microsoft sagt "Implementing Finalize methods or destructors can have a negative impact on performance" - also es kann aber muss nicht.
Es wird damit begründet das der Garbage Cllector das Objekt dann zwei mal ansteuert, einmal um den Finalizer auf zu rufen und dann nochmal um es aus dem Speicher zu schmeißen. Das kann Performance Probleme geben wenn du sehr viele solcher Objekt hast.
Ich dachte an irgendwie sowas:
interface IConverter<T>
{
T FromText(string text);
string ToText<T>(T obj);
}
public class IntegerConverter : IConverter<int>
{
public int FromText(string text) { ... }
public string ToText(int obj) { ... }
}
Hab es grad hier im Forum getippt aber nicht getestet ob es überhaupt baut.
Aber jetzt wo ich es seh merk ich auch das man es so nicht in ein Dictionary bekommt - vermutlich hatte ich es aus dem selben Grund auch damals nicht gemacht ^^
Dravere schrieb:
man könnte auch statt der ListView ein DataGrid nehmen. Oder man erweitert ListView um DataSource . Gibt dazu auch ein paar Einträge im Internet.
Ich denke in zukünftigen Projekten werde ich wohl Abstand vom ListView nehmen - das DataGrid schein mir generell etwas mächtiger zu sein.
danke, .NetPhysiker
Dravere schrieb:
Ich sage es immer wieder, lest die verdammte Dokumentation
http://msdn.microsoft.com/en-us/library/system.io.streamreader.readline.aspx
MSDN schrieb:
Remarks
A line is defined as a sequence of characters followed by a line feed ("\n"), a carriage return ("\r"), or a carriage return immediately followed by a line feed ("\r\n"). The string that is returned does not contain the terminating carriage return or line feed. The returned value is null if the end of the input stream is reached.
Grüssli
Na, da hab ich wohl zu schnell die Doku gelesen. Hatte mir doch gedacht, dass es komisch ist, dass das nicht in der Doku steht...
Danke!
Achjeh, das ist eine dieser lustigen "params" Funktionen.
Wo er dann hergeht und ein leeres Array übergibt wenn man sie ohne Parameter aufruft. Was bei der speziellen Funktion natürlich so richtig Sinn macht. Wäre vielleicht auch besser sie hätten da ne Möglichkeit geschaffen anzugeben, dass mindestens ein Objekt erwartet wird.
Ca. 3 sek. Google Suche ergab diese ersten beiden Treffer:
http://www.c-sharpcorner.com/UploadFile/dsandor/ActiveXInNet11102005040748AM/ActiveXInNet.aspx
http://www.codeproject.com/KB/cs/CreateActiveXDotNet.aspx
Und, damit es nicht so schwer für den Anfang für Dich ist, hier: http://lmgtfy.com/?q=active+x+c%23.net
Gut Schuß
VuuRWerK
Wow, da bin ich mal ne Woche win Paar Tage im Urlaub und dann stehe ich vor Romanen an Hilfestellung. Scheinbar hat es sich schonmal gelohnt, dass ich mich nochmal mit den Grundlagen befasst habe. Bei den Klassen sieht man ja immernoch Verbesserungsbedarf, aber ich dachte mal, dass ich die Kenntnisse versuche selber anzuwenden, was ja nicht so schlecht war.
Eingegangen bin ich auf deine Vorschläge, lieber David W, weil du offensichtlich der Fachmann bist und weshalb sollte ich mein Programm nicht auch dementsprechend aktualisieren. Alleine die Gestaltung der Tierunterklassen ist viel übersichtlicher und vom Programmcode kürzer, was beim Scrollen hilft;)
Außerdem konnte ich die Fehler nunmehr arg reduzieren.
Ich muss nun mal alles versuchen anzupassen und zu tüfteln und hoffe, dass ich dadurch nun viel weiter komme. Ich melde mich, wenn es noch irgendow speziell im Verständnis hakt;)
Groupboxen, Bilder und Transparenz ... das ist sehr übel.
Ich würde erstmal die Transparenz deaktivieren und das Bild beim ersten laden der Anwendung zerstückeln. Jede Groupbox bekommt dann den passenden Ausschnitt als Backgroundimage zugewiesen.
Damit solltest die Anwendung wenigstens benutzbar werden.
Oder noch besser: Verzichte auf dieses nervtötende Hintergrundbild und wähle einen dezenten Farbverlauf.
Dann wähl doch deine Namensräume so wie MS. Packe das zusammen was zum System gehört usw. Kannst es auch in UI und Core aufteilen. Also Möglichkeiten sind da viele