Inverse Darstellung erzwingen

  • Hallo Profis,


    wenn ich mit der TAB Taste von einem Editfeld ins nächste wechsele dann wird eventl. vorhandener Text blau hinterlegt und bei der Eingabe des 1. Zeichens per Tastatur gelöscht.


    Nun möchte ich aber diesen Effekt auch mit mit der ENTER-Taste erhalten. Das heist, ich drücke auf dem Zahlenfeld die ENTER Taste und der Focus springt zum nächsten Editfeld und wie bei der TAB Taste wird eventl. vorhandener Text blau hinterlegt und bei Eingabe des 1. Zeichens gelöscht.


    Ich meine, das vor Jahren Profellow solch eine Funktion zur Verfügung stellte. Leider weis ich nicht, wie das in XProfan zu realisieren wäre. Habt Ihr in Eurem Fundus vielleicht so etwas?

    Viele Grüsse
    Mike


    Windows 7 ultimate
    Xprofan X2

  • @ Frank, Dux


    vielen Dank, da ich aber mit dem SubCassing auf Kriegsfüß stehe, ( ich empfinde es als unheimlich schwer. Vielleicht könnte man da mal einen Kurs oder Ähnliches starten) habe ich jetzt nur mit SendMessage() gearbeitet.

    Viele Grüsse
    Mike


    Windows 7 ultimate
    Xprofan X2

  • Du brauchst auch kein Subclassing. Wenn Du messages.ph mit $H eingebunden hast, reicht auch:

    Code
    <...>
        ElseIf (%Key = 13)
          SendMessage(%getfocus, ~EM_SETSEL, 0, -1)
        <...>


    Du kannst ohne messages.ph auch einfach $B1 für ~EM_SETSEL nutzen.


    Gruß
    Roland

    (Intel Duo E8400 3,0 GHz / 4 GB RAM / 250 GB HDD / ATI Radeon HD4770 512 MB / Windows Vista - ausgemustert zum Verkauf)
    AMD Athlon II X2 2,9 GHz / 8 GB RAM / 500 + 1000 GB HDD / ATI Radeon 3000 (onboard) / Windows 10(64) - XProfan X4


    http://www.xprofan.de

  • cyberangle
    Ein simpler Beispielcode, Deinerseits, der es uns abnimmt ein Fenster mit
    Edit zu erstellen, so das nur noch minimal ergänzt wird, wäre eine gute
    Idee ;)
    Ansonsten beantworte ich rein theoretische Fragen genauso, wie sie gestellt
    wurden :D (bin auch ein fauler Sack :lol:)


    Zeitgleich mit Roland

  • @ Thomas,


    mein Programmauszug wird eine Kassenverwaltung und die 5 Felder dienen der Dateneinbgabe, da hätte ich natürlich gern den Text links- und die Zahlen rechtsbündig.


    Um nur Zahlen zuzulassen nehme ich die NEdit. dll von Frank, da ich mit dem SubCassing auf Kriegsfuß stehe. Währe der Code denn schneller mit SubCassing, oder was ist der Vorteil:?::?::?:

    Viele Grüsse
    Mike


    Windows 7 ultimate
    Xprofan X2

  • Zitat

    Währe der Code denn schneller mit SubCassing, oder was ist der Vorteil?


    Nein, er würde langsamer, wenn du das direkt mit XProfan machst, was jetzt die Dll macht. Vorteil ist nur, dass du keine Extra-Dll benötigst. Wird es mal ein 64-Bit XProfan geben, dann müsstest du dein Programm dann umschreiben, weil es die Dll nur als 32 Bit gibt.

    Gruß, Frank

  • Und wenn Du die "Return" abfrage mit in die Subclass packst, bist Du auch
    nicht mehr auf einen bestimmten Fensterstyle angewiesen, weil %Key = 13
    geht anscheinend nur wenn 512 im Fensterstil enthalten ist.
    Fensterstile, abgesehen wenn sie das Aussehen ändern, sind mir ein Greuel,
    mal geht das und mal das, dem gehe ich lieber ganz aus dem Wege ;)

  • Zitat von Frabbing;867630

    Stimmt, die Unterleitung in Stil 512 - oder nicht ist eines von XProfan schlimmsten Sünden. ;)


    Aber ohne 512 reagieren eben leider Controls nicht ganz so, wie erwartet. Das sollte dann schon so sein wie mit Dialogstil, wenn ich Controls direkt auf dem Hauptfenster habe. Da möchte ich schon mit der Tab-Taste arbeiten können und beim Mausklick erst bei Loslassen eine Reaktion. Was mich mehr stört, ist das uneinheitliche Handling beim Systemmenü und dem Schließbutton in der Titelleiste. Gerade der Schließbutton ist nur mit Dialogstil abfragbar (oder eben separat über Usermessages wenn ich das Systemmenü selbst behandle).
    Wenn's aber zu vereinheitlichen geht, dann bin ich dafür;).


    Gruß Volkmar

  • Erstmal wäre die Frage zu klären, was ist Stil 512?
    Auf jedenfall ist es kein Fensterstil der API sondern irgendetwas
    Profanspezifisches. Ich arbeite lieber mit Konstanten, deren Namen sagen
    was aus und ich kann in der MSDN nachschlagen, wenn die normale
    Hilfe nicht ausreicht. Diese Fensterstile ignoriere ich, ~WM_CLOSE muss
    immer funktionieren, ansonsten gibt es Speicherlecks, weil die Dispose
    stellen garnicht angesprungen werden usw. usw.
    ~WS_DLGFRAME usw. ist es anscheinend nicht :D


    Immer drinnen oder immer draußen ist mir zu unsicher. Dialogartikes
    Verhalten wird heutzutage immer seltener eingesetzt, obwohl es manchmal
    hilfreich sein kann. Man kann das Verhalten aber notfalls per API nachbilden,
    was mir persönlich dann lieber ist.

  • Ich habe schon Controls auf dem Hauptfenster. Meistens. Also ist Dialogartiges zumindest bei mir nicht so selten. Und gerade da ist ja ein eindeutiges Ende drin, nämlich %Key=2 und damit auch sauberes Disposen. Alles über API machen geht nur für Experten. Und wenn ich das mache, dann, mal Grafikformate, Musik und DBase ausgenommen bin ich genau so gut mit simplen Pascal dran. Macht aber nicht so viel Spaß wie XProfan :lol:.


    Gruß Volkmar

  • Ich meinte so Sachen, wie Button, wenn selektiert, mit Tastatur drücken,
    das geht heutzutage eben mit der Leertaste und nicht mit Enter, wie früher :D,
    von Edit zu Edit mit Tab und nicht mit Enter, usw.
    Soll nicht heißen, früher war alles schlechter, sondern standards ändern sich
    und da muss man eben mit, ob man will oder nicht.
    Ich sehe zwar ein, das DBase auf dem ersten Blick manchen leichter
    erscheint, aber dem ist gar nicht so, SQL ist wesentlich einfacher und
    flexibler, man muss es einfach mal ausprobieren.


  • Von Control zu Control (nicht nur Edit) macht ja der Dialogstil. Und die Buttons mit der Leertaste auch. Enter ist dann nur für den Def-Button relevant. Den Dialogstil verwende ich doch nicht, weil er ein veraltetes Bedienschema ist. Ganz im Gegenteil ist der schon auf der Höhe der Zeit.
    DBase war eines der Dinge, was ich in einem einfachen Pascal erst mal nicht habe.


    Gruß Volkmar

  • Einen hab ich noch vergessen:


    Zitat von ts-soft;867641

    Erstmal wäre die Frage zu klären, was ist Stil 512?
    Auf jedenfall ist es kein Fensterstil der API sondern irgendetwas
    Profanspezifisches. ...
    ~WS_DLGFRAME usw. ist es anscheinend nicht :D


    Ne stimmt. Ist kein Fensterstil. ist die Funktion, die sich hinter Windows-Dialogen verbirgt. Also durchaus eine windowstypische Funktion, die MS auch ausgiebig nutzt. Wird bei gesetztem Dialogstil anstelle der DefWindowProc gerufen. Deshalb auch &WinProc und &WinDProc. Ist in XProfan eben nur als Fensterstil dargestellt und sollte die Anwendung für den Einsteiger vereinfachen. Wenn anders, also windowsgerechter, dann brauchte es eben zwei Möglichkeiten, ein Hauptfenster zu erstellen. Und CLS wäre nur einer Möglichkeit zuzuordnen. XProfan ist eben nicht nur für API-Virtuosen gemacht ;).


    Gruß Volkmar

  • Für mich vereinfacht sich dadurch nichts, ich bin nur verwirrt. Hab früher
    immer von 26 bis über 1000 alles mögliche rumprobiert, bis es so ging, wie
    ich es wollte oder hab es einfach sein gelassen.
    Inzwischen nutze ich XProfan überwiegend als Batchsprache, wo diese
    komischen Stile nicht mehr interessieren.


    Da es auch viele Menschen gibt, die irgendwelche Hexzahlen in Messages
    schreiben und der Meinung sind, sie Wissen am nächsten Tag noch was das
    bedeutet und auf dem Vorzug auch mal in der MSDN nachzuschlagen ver-
    zichten, stehe ich vielleicht in dieser Beziehung alleine da :D, worüber ich
    dann aber auch nicht verärgert wäre.

  • Zitat

    Wenn anders, also windowsgerechter, dann brauchte es eben zwei Möglichkeiten, ein Hauptfenster zu erstellen.


    Ehrlich gesagt, ein "Hauptfenster" ist doch schon untypisch. Ist auch nichts anderes als ein Parent der Dialogfenster. Und genaugenommen selber auch nur ein Child des Desktop. Ich finde es seltsam, das das unbedingt anders reagieren sollte.

    Gruß, Frank

  • Zitat von Frabbing;867661

    Ehrlich gesagt, ein "Hauptfenster" ist doch schon untypisch. Ist auch nichts anderes als ein Parent der Dialogfenster. Und genaugenommen selber auch nur ein Child des Desktop. Ich finde es seltsam, das das unbedingt anders reagieren sollte.


    Ist aber das Top-Level-Window der Anwendung. Heißt nur in XProfan Hauptfenster. Und wenn ich in Pascal ein generisches Fenster für ein Programm erstelle, dann reagiert das auch bezüglich von Controls wie das Hauptfenster von XProfan. Das Warten auf Loslassen der Maustaste über einem Control, bevor es ein Clickereignis gibt und die besondere Verwendung der Tab-Taste zum Beispiel sind da erst mal nicht drin. Dieses anfängliche "Haupt-"Fenster überläßt es dem Anwender (Programmierer) erst mal, alles selbst zu machen. MS-Paint hat eben zum Beispiel keine Buttons, dafür aber mehr Freiheiten. Jede Botschaft, die das System nicht unbedingt braucht, kommt unverändert durch.
    Ich denke mal, das dachte sich MS dabei, zwei verschiedene Fensterfunktionen anzubieten. Einmal maximale Freiheit und einmal erhöhten Komfort, also das ganze Benutzerinterface schon eingebaut. Das oberste Fenster einer Anwendung eben mit maximaler Freiheit und die untergeordneten Fenster mit dem entsprechenden Komfort in der Bedienung.
    Im alten Profan gabe es den Dialogstil anfänglich auch nicht. Unschön, wenn man da ein paar Controls auf dem Fenster hatte, die nicht so reagierten, wie in jedem anderen Programm. Also Deine Idee, Dialogstil immer drin könnte mir gefallen. Ob es dabei aber nicht doch irgendwas gibt, was dann wieder nicht geht?


    Gruß Volkmar

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!