So. Meine Arbeit ist getan
ich habe nun die Variante mit onpaintbackground genommen, welches meinen gesamten Hintergrund geschwärzt hat. dann habe ich einfach mit der TransparencyKey Funktion das schwarz auf transparent gesetzt. Die Hintergrundgrafik habe ich dann in eine PictureBox gesetzt und in den Hintergrund geschickt.
Ist zwar keine professionelle Lösung, aber hat den Effekt erzielt.
Danke, Thread erledigt.
MFG Deffcon
Argus Magnus schrieb:
Dieser Beitrag kann getötet, bzw. gelöscht werden..
Wozu? Besser wäre doch, wenn du hier dann einmal was noch dazufügst, dass jemandem helfen kann, welcher in der gleiche Situation ist. Ein Forum kann auch als Wissensdatenbank dienen
Grüssli
waldmensch7 schrieb:
@ dravere: ich muss dir widersprechen, in C++/CLI funktioniert das aber! hab es ausgetestet
Ich programmiere auch C++/CLI und das was du uns hier präsentiert hast, funktioniert so ganz sicher in C++/CLI auch nicht. Dann machst du nämlich in C++/CLI was anders. Wahrscheinlich machst du in C++/CLI, was du weiter vorne gezeigt hast. Aber das ist definitiv was anderes.
Deine Zuweisung an Daten.RName findet im Konstruktor statt. Wenn sich später dann einmal F2textBox1.Text ändert, springt dieser Wert nicht automatisch auf Daten.RName über. Dort bleibt natürlich der alte Wert enthalten, welcher du im Konstruktor zugewiesen hast. Und genau gleich läuft dies auch in C++/CLI ab.
Wenn du den Code aus C++/CLI willst:
namespace WindowsFormsApplication1
{
public partial class Form2 : Form
{
public Region Daten
{
get
{
Region daten = new Region();
daten.RName = F2textBox1.Text;
daten.LName = F2textBox2.Text;
return daten;
}
}
public Form2()
{
InitializeComponent();
}
}
}
waldmensch7 schrieb:
...und was jetzt an meinem code falsch ist, weiß ich immer noch nicht - anstatt dass mich jeder auf die fehlenden grundlagen aufmerksam macht, hätte man doch was schreiben können, was zur lösung beiträgt? verstehe ich nicht...
oder ist das nur ein forum für cracks?
Dieses Forum ist nicht dazu gedacht, den Leuten das Lesen abzunehmen. Das ist ein Forum mit freiwilligen, da ist es doch nur höfflich, wenn man sich selber zumindest mal mit den Grundlagen auseinandersetzt, bevor man hier angerennt kommt.
Grüssli
nimm die GDI+ lib dafür, das reicht, dx etc wäre dafür zu overkill alles erstmal zu initialisieren zu müssen wenn du mit .net arbeitest. ist echt einfach zu handhaben, musst nur systemgünstig damit arbeiten, also nicht jedesmal nen neuen brush bei jedem durchgang erzeugen etc.
Hey Hellsgore,
Ja, gut komplett bei allen datums stellen die damit zusammen hängen durchdebuggt habe ich noch nicht. Werde ich Montags gleich mal machen.
Allerdings probiere ich nun schon seit Montag diesen bug zu reproduzieren, und ich denke eigentlich ich habe alles abgedeckt.
Trozdem läuft es bei mir immer richtig.
Daher bin ich nicht überzeugt das ich durch debuggen die Fehlerstelle finde, immerhin ist es nicht so leicht beim debuggen eine fehlerhafte stelle zu finden die bei mir bisher keine fehler geworfen hat
Hans1988888 schrieb:
1. Frage wie bekomme ich den Pfad meines aktuellen Projektes heraus?
Hintergrund ist, das ich gerne zur Laufzeit in dem Pfad, wo die EXE ausgeführt wird ein Workverzeichnis erstellen möchte, in dem persistente Daten gehalten werden.
Du könntest Dir auch mal Isolated Storage anschauen, der ist dafür gedacht:
http://msdn.microsoft.com/en-us/library/bdts8hk0(v=VS.90).aspx
hustbaer schrieb:
Das erste aus dieser Liste. Ist einfach nur ne Beobachtung, sowas passiert schnell mal. Also ich sage nicht dass man sein Gehirn ausschalten sollte. Ich sage auch nicht dass das nur jemandem passieren kann der sein Gehirn ausgeschaltet hatte. Ich glaube ganz im Gegenteil, dass man sein Gehirn beim Refactoring für andere Dinge braucht, und daher schnell mal solche "Kleinigkeiten" übersieht.
Ok, dann passiert das gelegentlich. Dies sei zugestanden. Dann kann ich aber auch beim Ersten "stutzen" an dieser Stelle das var durch den Typ ersetzen...
Außerdem ist es fraglich, dass man so einen komplexen Generic einfach in eine Funktion versteckt und die Generik so einfach wegkapselt.
hustbaer schrieb:
...weil?
Weil ich nicht glaube, dass man so eine gewaltige generische Konstruktion benutzt und dann jegliche Generik über Bord schmeißt und das Ganze dann auf einen Typen festnagelt.
Ich würde erwarten, dass MakeTheSpecialFoo() selbst auch noch ein paar Typparameter hat. Den Sprung von totaler Generik in quasi statische Typisierung halte ich für unrealistisch.
hustbaer schrieb:
Darüber könnten wir uns jetzt streiten.
Jederzeit.
hustbaer schrieb:
Sprechende Funktionsnamen sind gut, klar. Bloss irgendwo ist eine Grenze, und [...] wäre eindeutig zu lange und ... IMO einfach nur schlecht.
Ja, ein Name der die ganze Typisierung ausdrückt wäre zu "fett", aber ein Name der eine Ahnung vermittelt, was hier zurück kommt, kann deutlich kürzer und trotzdem sprechend sein.
Aber noch einmal der Kern meiner Aussage:
var nur auf anonyme Typen fest zu zurren, halte ich für zu extrem. Das geht schon in die "goto ist der Teufel-Ecke".
Ich stimme aber vollkommen zu, dass man var missbrauchen kann und damit die Lesbarkeit von Code deutlich verschlechtern kann.
Hi Dravere,
danke für die klare Antwort.
Das hatte ich schon angenommen, aber immer noch gehofft, irgendetwas übersehen zu haben.
Sind vielleicht für eine weitere Sprachversion ('C# 5.0') zusätzliche Features im Bereich generics im Gespräch?
Hallo zusammen,
ich habe ein Problem beim Deserialisieren folgendes XML Ausschnittes:
<fork>
<process>
<operation id="00000001-0001-0001-0000-000000000001" refWebserviceMethod="00000001-0001-0001-0000-000000000000"/>
</process>
<process>
<operation id="00000001-0001-0001-0000-000000000002" refWebserviceMethod="00000001-0001-0001-0000-000000000000"/>
</process>
</fork>
mit folgender Methode:
private processForkType deserialize(string xml)
{
StringReader xmlWriter = new StringReader(xml);
XmlSerializer xmlSerializer = new XmlSerializer(typeOf(processForkType));
return xmlSerializer.Deserialize(xmlWriter);
}
Hier die Klasse für den Deserializer:
public partial class processForkType : object, System.ComponentModel.INotifyPropertyChanged {
private object[] processField;
private object[] process1Field;
/// <remarks/>
[System.Xml.Serialization.XmlArrayAttribute(Order=0)]
[System.Xml.Serialization.XmlArrayItemAttribute("fork", typeof(processForkType), IsNullable=false)]
[System.Xml.Serialization.XmlArrayItemAttribute("operation", typeof(processTypeOperation), IsNullable=false)]
public object[] process {
get {
return this.processField;
}
set {
this.processField = value;
this.RaisePropertyChanged("process");
}
}
/// <remarks/>
[System.Xml.Serialization.XmlArrayAttribute("process", Order=1)]
[System.Xml.Serialization.XmlArrayItemAttribute("fork", typeof(processForkType), IsNullable=false)]
[System.Xml.Serialization.XmlArrayItemAttribute("operation", typeof(processTypeOperation), IsNullable=false)]
public object[] process1 {
get {
return this.process1Field;
}
set {
this.process1Field = value;
this.RaisePropertyChanged("process1");
}
}
public event System.ComponentModel.PropertyChangedEventHandler PropertyChanged;
protected void RaisePropertyChanged(string propertyName) {
System.ComponentModel.PropertyChangedEventHandler propertyChanged = this.PropertyChanged;
if ((propertyChanged != null)) {
propertyChanged(this, new System.ComponentModel.PropertyChangedEventArgs(propertyName));
}
}
}
Das Resultat ist, dass beide "operation"-Elemente in das process Field deserialisiert werden. das process1 Field ist leer.
Die processForkType Klasse wurde mit dem Visual Studio xsd-Tool erzeugt.
Hat jemand eine Idee was ich da machen kann.
Mfg
roskas
Mit SuspendLayout verhinderst du nicht das sofortige neu zeichnen. Bei SuspendLayout geht es nur um das Verhindern der Positionierungberechnung. Es wird dann nicht sofort die Methode OnLayout aufgerufen, wenn man zum Beispiel die Grösse verändert. Man sollte SuspendLayout und ResumeLayout auch nur dazu verwenden, wenn man mehrere Dinge am Layout auf einmal ändert.
Grüssli
Ganz allgemein: Da bin ich etwas überfragt.
Saifed the best schrieb:
Naja, das ist vom Auftraggeber so gewünscht. Sinn und Zweck ist, dass wenn einmal Daten abgeschickt wurden, man nicht zurück und wieder nach vorne navigieren kann, denn dann kommt ja diese Meldung "Seite nicht mehr gültig." Und das soll eben unterbeunden werden, indem man nach dem Posten von irgendwelchen Sachen von da an nicht mehr zurücknavigieren kann, um nicht zweimal an dieselbe Stelle mit dem Post zu kommen.
Hier könnte ich mir vielleicht noch Vorstellen, etwas über Interop zu erreichen. Das WebBrowser Control bei Windows Forms wrappt schliesslich nur IWebBrowser2 aus der WinAPI. Und in diesem COM Bereich gibt es eine Möglichkeit für die Manipulation der History. Mit IUrlHistoryStg kann man ein ClearHistory ausführen.
http://msdn.microsoft.com/en-us/library/aa752042.aspx
Wie man das genau Zusammenknüpft müsstest du aber noch selber rausfinden.
Saifed the best schrieb:
Nein, der Button ist nicht von mir. Was ich meine ist: Wenn die Seite einfach nur gewechselt wurde durch klick auf einen Link oder durch Eingeben der Adresse, dann ist das die eine Sache. Wenn aber jemand auf einen Button geklickt hat und somit Daten übertragen wurden (das, was in PHP in der _POST-Variable gespeichert wird), dann ist das was anderes. Und ich will nun gucken, ob das passiert ist, ob jemand Daten per POST übertragen hat, statt einfach nur ganz normal eine Seite zu wechseln.
Da bin ich dann aber völlig überfragt. Über COM käme man noch an ein paar zusätzliche Informationen beim Navigating Event. DWebBrowserEvents2::BeforeNavigate2 hat zum Beispiel auch Informationen über POST-Daten. Daher könnte man vielleicht dies so abfangen. Wäre aber nicht gerade schön.
Mehr fällt mir dazu leider nicht ein.
Grüssli
