Laden...

Forenbeiträge von mathias_f Ingesamt 12 Beiträge

10.02.2013 - 18:02 Uhr

Hallo Grumbler

Ich habe im VS Editor im "Standard" alles auf Englisch eingegeben.
Die Deutschen Texte habe ich bei der Auswahl "Deutsch" eingegeben also nicht spezifisch Deutsch(Deutschland) oder Deutsch(Schweiz). Dies mit dem Gedanken, dass ich damit alle deutschsprachigen Systeme abdecken kann.

Liegts daran, dass "de" neutral ist? Bei dem Versuch

SetUICulture("de")

motzt der nämlich bei der Laufzeit.

Ich arbeite auf einem CH System.

08.02.2013 - 03:14 Uhr

Guten Morgen allerseits,

Habe ein .NET 3.5 GUI WinForms erstellt.
Da kommt auch ein TreeView Element vor.

Nun kommts:
Wenn das Form localizable==false ist, dann funktionieren meine ToolTips auf den Knoten.
Wenn ich localizable == true habe gehen weder die deutschen noch die englischen (Standard) ToolTips.

ShowToolTips Eigenschaft des TreeViews ist == True gesetzt.

Wer kann helfen?

EDIT:
Zur Laufzeit habe ich ausgelesen:

MessageBox.Show( Thread.CurrentThread.CurrentCulture.ToString() );
MessageBox.Show( Thread.CurrentThread.CurrentUICulture.ToString() );

de-CH und de-DE
Seltsam dass die unterschiedlich sind. -> Probleme?

Und die Auswertung zur Laufzeit ergab dass ToolTipText bei den Nodes wirklich "" (leer) ist. Deshalb kommt auch kein ToolTip. Wieso wird der Text also "" obwohl ichs bei den Ressorucen eingegeben hab.
Was geht ist: Bei Programmstart die Texte per Code laden, dann werden diese auch angezeigt. Ist aber nicht komfortabel.

24.01.2013 - 08:03 Uhr

Guten Morgen allerseits

seit Stunden komme ich bei dieser Sache nicht vorwärts:
Windows 2000 mit .NET Framework 2.0 SP1 und Office Word XP meldet: > Fehlermeldung:

Assembly "MeineAssembly" oder eine Abhängigkeit nicht gefunden

Hintergrund:
Ich habe eine .NET DLL in C# erstellt.
Diese wiederum verwendet über einen Wrapper eine unmanaged DLL, welche wiederum eine DLL für die serielle Schnittstelle benötigt.

Die Techniken sind wie üblich:
.NET DLL verwendet [DllImport], EntryPoint sind decorated C++ Bezeichner.
Im .NET führe ich einen IntPtr als Zeiger auf das Objekt im unmanaged code.
Bei der verwendeten unmanaged DLL benutze ich __dllexport
Alle nötigen unmanaged dll liegen im System32. Keine COMs, kein regsvr32.
Die .Net DLL wurde mit

regasm name.dll /codebase /tlb:name.tlb

erfolgreich registiert.

Auf dem Entwicklungsystem (Win XP, VS2008) funktioniert natürlich alles.
Was mich besonders erstaunt: Der Code funktioniert im VB Scripting Host auf dem Win2k System! Also in einer einfachen vbs Datei kann ich sowohl CreateObject und anschliessend Methoden aus dem unmanaged ausführen.
Wenn ich den Verweis in Word XP mache, wird der auch erkannt aber bei Ausführung kriege ich immer die Meldung dass die Assembly oder Abhängigkeit nicht gefunden wurde.

Wieso kanns der Scripting Host und im VBA gehts ned?

Hier habe ich schon nachgelesen: .NET Assembly für COM sichtbar machen - funktioniert nicht

Ideen? Wer kann helfen? Thx

PS: ich weiss, Win2k und OfficeXp ist nicht mehr der Brüller 😃

Edit: Der alte Win 2k PC wurde ersetzt. Auf dem neuen läuft alles bestens.

04.11.2010 - 09:10 Uhr

danke für die beiträge

Wenn du Logik und Präsentation trennst, kannst du die entsprechenden Methoden mit ziemlicher Sicherheit in den Klassen unterbringen, die für die Logik zuständig sind.
Und hier kannst du dann wunderbar abstrakte Klassen etc. verwenden.

hmm, das klingt jetzt stark nach WPF, mache aber WinForms und "Auftrennen" würd ich auch gerne, klingt aber stark nach Mehrfachvererbung (!).

class UserControl1:UserControl, UserControlLogic{}

oder wie hast du das gedacht?

04.11.2010 - 09:04 Uhr

die klasse dazwischen noch abstrakt machen ?
Ich würde da virtuelle Methoden verwenden und ggf. überschreiben.

einfach weil es beim dem vererbenden UserControl um kein "echtes", voll funktionsfähiges handelt und somit davon keine instanzen gemacht werden sollen (ausser der desinger wills)

Mit normaler Klasse und virtuellen Methoden gehts wie beschrieben schon mal.

03.11.2010 - 12:59 Uhr

tagchen

habe einen stack von UserControls, nämlich
UserControl1:UserControl, UserControl2:UserControl, ..

Meine UserControls haben alle gleiche Methodensignaturen und etwa 4 Member vom gleichen typ sind immer nötig.

mein erster, liebster Ansatz war

public abstract class GenericUserControl:UserControl
{..}

und

public partial class UserControl1:GenericUserControl

( vorher:

public partial class UserControl1:UserControl

)

-> d.h ich ha ne "Zwischenschicht" eingebaut. Jetzt reklamiert der Designer da er mit der abstrakten Klasse keine Oberfläche zeichnen kann. Dabei würde ja der base() Konstruktor von UserControl reichen. Kann man das steuern?

Falls nein, gibts noch den Weg über Interface, wobei ich aber dann die 4 Member glichen Typs jedesmal ins UserControlxy packen muss... da ich nur Methoden in der Schnittstelle hab.
also:

public partial class UserControl1:UserControl, IUserControl{}
  1. Möglichkeit: keine abstrakte Klasse aber mit virtual Methoden:
public class GenericUserControl:UserControl
{
  virtual void Foo(){ MessageBox.Show("Dummy Foo"); // muss impl sein, kann überschrieben werden
}

tja, was ist nun gutes Design?

01.11.2010 - 11:38 Uhr

dachte schon ich hätt die ideale Lösung:

public override void BringToFront()
        {
            base.BringToFront();
            RefreshData();
        }

da ich Bringtofront sowieso aufrufen muss, wär auf diese Weise alles ok.

wäre... leider ist Bringtofront nicht abstract bzw virtual.. 😦

mit würds

public virtual void Refresh()

gehen.. aber da hab ich wieder einen Aufruf mehr:

Werde jetzt noch eine Methode probieren:

public void ShowUC()
{
BringToFront();
RefreshData();
}
diese wird aber nicht sichtbar sein wenn ich mit


foreach( Control uc in splitContainer.Panel2.Controls )
            {
                try
                {   
                    if( uc.Tag.ToString() == e.Node.Name )
                    { ...

durchgehe. Sonst müsst ich noch eine abstrakte Klasse BaseUC machen. Oder?

Der Nachtei bei visible bzw show hide ist dass ich explizit alle uc zuerst hiden muss um dann das gewünschte anzuzeigen mit show. sonst ist ein UC möglicherweise visible aber nicht in front 😦

01.11.2010 - 08:05 Uhr

Danke für eure Posts

um einen Aufruf komm ich also nicht herum. Entweder explizit focus setzen (Event nutzen) oder meine eigne UC.Refresh() aufrufen.

Grüsse aus der Schweiz.

29.10.2010 - 16:04 Uhr

tagchen

Form mit SplitContainer
links TreeView, rechts mehrere UserControls übereinander (Z Order)

TreeView.AfterSelect -> UCxy.BringToFront()

Nachdem ich also alle UCs in Panel2 geladen hab, zeige ich beim TreeView Klick das gewünschte an.

Nun will ich aktuelle Daten eines Geräts über RS232 auslesen und zwar erstens bei "Load" Event des UCs und zum anderen immer wenn es aktiviert/sichtbar wird.
Load Event gibts. Ok. Passiert aber nur 1x (wenn ich nicht remove/unloade).
Leider gibts keinen "Activated" Event wie bei Form worauf ich die Daten aktualisieren könnte.

Meine momentane Abhilfe:
TreeView.AfterSelect -> UCxy.BringToFront(), dann UCxy.Focus()
Mit dem Focus() wird der "Enter" Event gefeuert und ich hab meinen Trigger.
Unschön: das Formular lädt nicht selbstständig, sondern muss immer "von aussen" gefocust werden.

ähnlich: UserControl AfterLoad-Event?

Gibts bessere Wege?

16.09.2010 - 09:03 Uhr

👍
Danke für die Antworten und Hinweise (VS2010)

hab mich nun für die leserlichere Variante entschieden und mache bei Bedarf eine Klasse mit Eigenschaften (vgl. Control.Margin. ..).

14.09.2010 - 15:23 Uhr

Danke für die Links!

Wählen Sie leicht lesbare Bezeichnernamen aus. Beispielsweise ist eine Eigenschaft mit dem Namen HorizontalAlignment im Englischen besser lesbar als AlignmentHorizontal.

hier möcht ich zur Diskussion anregen:

Wie sehen andere das?
Wenn ich noch AlignmentVertical hab ists geordneter und klingt Objekt bezogen, beinahe wie Alignment.Horizontal = true;

Wäre es bei 2 oder mehr Eigenschaften gleichen Typs (im Sinne Simonyi) (Länge oder Anzahl, etc) also besser gleich zu gruppieren und einen struct / class mit allen Alignments und Lengths zu machen?

Object.Alignments.Horizontal
Object.Alignments.Vertical

g

14.09.2010 - 14:12 Uhr

tagchen leute

mein erstes posting in die runde wink

mache mir gerade gedanken zum naming von Eigenschaften.

a) m_dLengthEdgeA
b) m_dEdgeALength
c) LengthEdgeA
d) EdgeALength

-> Rect.LengthEdgeA

1: verwendet ihr noch hungarian (system) notation?
2: mir gefällt irgendwie a) bzw c) denn es ist vorangestellt WAS es ist: eine Länge, zudem sind bei intellisense alle Lengths zusammen, falls ich noch eine LengthIrgendwas habe.. bei IrgendwasLength und EdgeLength sind die in der alphabetischen Liste getrennt

Was denkt ihr?

g