Re: OT

Herfried K. Wagner [MVP] wrote:
"Frank Dzaebel" <Post@xxxxxxxxxxxxxx> schrieb:
Wie sieht diese Vorgehensweise denn aus, wenn dann nachträglich ein Short Cut dazu kommt?

Angenommen, man wäre dem Vorschlag gefolgt,
und hätte den Hack gewagt, und "\t irgendwas"
zugefügt, kommt reproduzierbar Zeichensalat heraus,
wenn vorher ein Shortcut da war.

Ja, wenn, aber Deine Prämisse ist falsch. Wenn man nämlich ein eigenes Tastaturkürzel vergeben will, wird man keines setzen.

Ich denke dass das jemand nachtrÄglich dann via dem ShortCut - Property tut, was im Lebenszyklus eine Anwendung nicht soo unrealistisch ist, kommt aber natürlich aufs Projekt an.

Allein das zeigt ja jedem vernünftigen Menschen
bereits die Unsinnigkeit dieses undokumentierten
nicht supporteten Verhaltens.

Das Verhalten ist dokumentiert. Was Du mit "supportet" meinst, weiß ich nicht. Für Windows Forms unter Windows ist das Verhalten aber naheliegend, da Windows Forms eben von Microsoft nur für Windows unterstützt werden und da eine Kapselung der Win32-Benutzerschnittstellen darstellen.

Wenn in der Doku stehen würde:
Windos Forms is just a nice Frontend to Win32 but everything that worked in Win32 will work in WindowsForms too

WÄre ich bei dir, tut es aber nicht AFAIK :-).

Javas AWT hat auch versucht unter jeder Platform das jeweiliege Toolkit zu unterstützen, als war es in Windows auch ein Wrapper um Win32 oder ein Subset davon, dennoch hat man diort nicht das selbe tun konnne, die sind allerdings auch drauf gekommen das das nichts kann und haben ihr Swing gebastelt, und MS eben sein WPF.

Der Zeichensalat ist
natürlich ebenfalls nicht dokumentiert (logisch). Braucht
er auch nicht, es darf nur die Framework-Doku
benutzt werden.

Wenn man das Funktionsmerkmal so benützt, wie es vorgesehen ist, erhält man keinen Zeichensalat.

Entwickler von Framework-Runtimes für andere
Betriebssysteme brauchen sich nur an die
Framework-Doku zu halten. Das OS kann da ganz
andere Menü-Sytax haben.

Windows Forms = Win32!
== // wir sidn in eienr C# Gruppe :-D

Wenn man einen Nachbau einsetzt, der nicht auf den Windows-eigenen Steuerelementen beruht, darf man sich nicht wundern, wenn nicht alles wie erwartet funktioniert. Der Fehler liegt dann aber nicht am Code, sondern am Nachbau, der die Win32-Steuerelemente nicht 1:1 abbildet.

Wenn ich mich ans Forntend halte, und der Nachbau das auch tut dann kann ich mich drauf verlassen, wenn ich Features benutze die im UNterbau sind, die aber nirgendest so als Features stehen dann bin ich selber schuld wenns mal nimmer geht.

Ich hoffemal einfach dass dieses Verhalten wirklich nicht in der Menu - Doku von .NET beschrieben ist, wenn es das ist sorry.

.NET sollte doch bitte platform übergrteifend sein und Hacks die in
Win32 hinhaun sollten bitte nicht in .NET verwednet werden, was das
angeht bin ich voll bei Frank.

ja, mit der Betonung auf "Hack", denn selbst in Windows gilt:
das Framework sagt nichts in der Dokumentation
darüber aus, dass es die Legacy-Menüs 100% funktional
unterstützt werden.

Das behauptet auch niemand. Aber die Dokumentation sagt zweifelsfrei, daß der Namensraum die von Win32 gebotenen Möglichkeiten (teilweise) zugänglich macht, also eine Kapsel darum darstellt.

*teilweise* ist das Zauberwort denk ich, sie schreiben nicht dass System.Windows.Fomrs sich gleich verhält.

MemoryLeaks oder Zeichensalat, der bei der Benutzung
auf die (Hack-) Art (mit "\t") entsteht, sind deswegen auch
nicht von MS zu bereinigen, denn es ist nicht supported,
auch nicht im Windows-Szenario.

Es entstehen weder Speicherlecks noch ein Zeichensalat. Prämisse: Der Entwickler ist bei Sinnen.

:-).

LG
Nicolas


--
http://www.student.tugraz.at/nicolas.pavlidis/websciencemaniac/
.

Relevant Pages

  • Re: Win32 TSR program skeleton
    ... under windows a "comsole" is just a thing used for display. ... are not avaible to Win32 apps, and are not created for Win32 console ... I need to write a TSR that does some periodical checks over another ... You should say that I can simple pipe the output to my app, but, ...
    (microsoft.public.win32.programmer.kernel)
  • Re: I really do like OS X but . . .
    ... Win32 is just an environment, ... >Windows right now, would be from .NET or Java. ... >Microsoft took an excellent kernel like NT, ... Only Apple. ...
    (comp.sys.mac.advocacy)
  • Re: linux to windows porting help
    ... Presently i am working on win32 console applications. ... PostThreadMessage - for Message queue between process and its ... donn have any windows handle so unable to use these functions... ...
    (comp.programming)
  • Re: As programmers...have we come a long way since 1993?
    ... If 'win64', as the main OS of PC users, ... is notably different in compatibility with old win32 software then ... the case Win64 should be largely tolerant of win32, ... > Look at Windows XP and Windows 2000, with that very scary DCOM exploit. ...
    (comp.programming)
  • Re: OT
    ... "Frank Dzaebel" schrieb:> von Windows Forms] ... Meine Dokumentation zu Windows Vista enthält folgenden Eintrag: ... indem wieder und wieder andere Interpretationen für ... Bei jedem Steuerelement. ...
    (microsoft.public.de.german.entwickler.dotnet.csharp)
Quantcast