Tabulator will nicht



  • Heiho

    Ich hab hier einige Elemente in einer ChildView, unter anderem Edit controls, und nun möchte ich die möglichkeit von einem Edit zum andreren Edit zu springen mittels der Tabulator taste.

    Nach längeren suchen mittels Google oder hier hatte ich ein paar sachen ermittelt und ausprobiert, nur leider brachte alles nichts.
    (Kann nicht mehr wiedergeben was ich alles probierte)

    Daher die Frage, wie kann ich "Tab" aktivieren, WS_TABSTOP|WS_GROUP haben die Edit-Elemente bereits.

    Danke und Gruß

    David



  • WS_TABSTOP ist schon korrekt. Die Tabulatorenreihenfolge entspricht anschließend der Reihenfolge, in der die Controls erstellt worden sind.



  • Die reihenfolge ist nicht das Problem, vielmehr das ein druck auf die Tabulatortaste nichts bewirkt {o;


  • Mod

    Bau in PreTranslateMessage Deines Views für Tastatureingaben ein IsDialogMessage ein. In der MFC gibt es dafür die Funktion CWnd::PreTranslateInput, die das kappselt.

    BTW: Warum hast Du keinen CFormView verwendet?

    Dein Code sollte in etwa so wie der aus CFormView aussehen:

    BOOL CFormView::PreTranslateMessage(MSG* pMsg)
    {
    	ASSERT(pMsg != NULL);
    	ASSERT_VALID(this);
    	ASSERT(m_hWnd != NULL);
    
    	// allow tooltip messages to be filtered
    	if (CView::PreTranslateMessage(pMsg))
    		return TRUE;
    
    	// don't translate dialog messages when in Shift+F1 help mode
    	CFrameWnd* pFrameWnd = GetTopLevelFrame();
    	if (pFrameWnd != NULL && pFrameWnd->m_bHelpMode)
    		return FALSE;
    
    	// since 'IsDialogMessage' will eat frame window accelerators,
    	//   we call all frame windows' PreTranslateMessage first
    	pFrameWnd = GetParentFrame();   // start with first parent frame
    	while (pFrameWnd != NULL)
    	{
    		// allow owner & frames to translate before IsDialogMessage does
    		if (pFrameWnd->PreTranslateMessage(pMsg))
    			return TRUE;
    
    		// try parent frames until there are no parent frames
    		pFrameWnd = pFrameWnd->GetParentFrame();
    	}
    
    	// don't call IsDialogMessage if form is empty
    	if (::GetWindow(m_hWnd, GW_CHILD) == NULL)
    		return FALSE;
    
    	// filter both messages to dialog and from children
    	return PreTranslateInput(pMsg);
    }
    


  • Hei, funktioniert klasse {=, Ich habe in der PreTranslateMessage das CWnd::PreTranslateMessage mit CWnd::PreTranslateInput ausgetauscht, nun funktioniert alles wie gewollt, danke dir. {=

    Martin Richter schrieb:

    BTW: Warum hast Du keinen CFormView verwendet?

    Weil die gesamte Oberfläche ausnahmslos dynamisch ist (Bei der Erstellung, Position und Größe aller Elemente),
    Das Dialog Fenster würde komplett leer sein, sehe deshalb kein nutzen davon.


  • Mod

    Mr Evil schrieb:

    Martin Richter schrieb:

    BTW: Warum hast Du keinen CFormView verwendet?

    Weil die gesamte Oberfläche ausnahmslos dynamisch ist (Bei der Erstellung, Position und Größe aller Elemente),
    Das Dialog Fenster würde komplett leer sein, sehe deshalb kein nutzen davon.

    Na und?
    Aber die Basisfunktionen, wie z.B. die Tastatureingabe, das merken, des letzten Controls, dass den Focus, hat. Das automatische Selektieren, wenn ein Control angesprungen wird. Das Handling von Default-Buttons. All das ist in CFormView implementiert...
    Auch das Rollen muss man dem nicht bebringen, etc. etc. etc.

    Selbst wenn alles dynamisch ist. Das habe ich auch oft genug, wähle ich für solche Fälle immer CFormView!

    Basisklassen sind dafür da die Eigenschaften zu erben 🕶



  • Ich möchte nun eigentlich nicht viel drum herum reden und vom Thema abweichen (welches ja schon gelöst ist)

    Um deine Beispiele aufzugreifen:
    -> die Tastatureingabe:
    Tastatur eingaben sind nur in ein paar Editboxen möglich und werden dort schon gesondert gehandhabt (Spezielles verhalten erwartet),
    Shortcuts gibt’s nicht und soll auch nicht (Tabulator ist die einigste ausnahme)

    -> das merken, des letzten Controls, dass den Focus, hat:
    Absolut uninteressant.

    -> Das automatische Selektieren, wenn ein Control angesprungen wird:
    nicht erwartet, müsste ich deaktivieren

    -> Das Handling von Default-Buttons:
    gibt’s nicht, auch nicht geplant

    -> Automatisches Rollen:
    nicht erwartet, müsste ich deaktivieren

    Wie gesagt, ich brauch und erwarte keine verhalten wie ein Dialog sie bietet, und habe wie gesagt kein nutzen davon,
    vielmehr find ich es einfacher in einer ChildView zu arbeiten, vor allem was größen, Positionen usw. angeht.

    "Basisklassen sind dafür da die Eigenschaften zu erben"

    Genau, darum erbe ich nicht von FormView da ich (absolut) keine Verhalten eines Dialog erwarte ggf. sogar deaktivieren müsste.


Anmelden zum Antworten