4. Nach Upgrade von c++ VS2003 auf VS2005 Combo-Boxen defekt

Nach Upgrade von c++ VS2003 auf VS2005 Combo-Boxen defekt

  • E

    Hallo,
    mein Programm wurde mit Visual Studio 2003 erstellt.
    Es ist eine MDI-Anwendung und enthällt mehrere Dialoge.

    Das Programm soll nun nach und nach ein upgrade erfahren.
    Zunächst mal nach VS 2005.
    Fast hätte es auch geklappt.
    Ich habe das .sln-File mit VS2005 geöffnet, und der Upgrade-wizzard hat den Rest gemacht.
    Einige Anpassungen am Quellcode und das Programm startet und läuft!

    Bei der Kontrolle der Dialoge musste ich leider feststellen, dass sich die
    Combo-Boxen nicht mehr öffnen lassen. Es erscheint nur noch ein schmaler schwarzer Balken,
    der dabei auf und zu geht.

    Ich habe die Dialoge dann im Designer getestet, ohne Schwierigkeiten.
    Auch sind dort die Grössen für die geöffnete Combo-Box korrekt definiert und erkennbar.

    Ich habe das Programm wieder mit VS2003 geöffnet. Dort lässt es sich ohne Quellcode-Änderung
    immer noch mit dem auf VS2005 angepassten Quellcode einwandfrei betreiben, und die Combo-Boxen
    funktionieren wieder. Dann wieder zurück auf VS2005 und Combo-Boxen wieder kaputt!

    Ich habe dann mit VS2003 ein kleines Dialog-Programm gemacht und dieses auf gleiche Art
    nach VS2005 migriert. Hier funktionierte aber alles unter VS2005! Keine Probleme mit der Combo-Box!

    Ich habe auch alle Verweise auf VS2003-Verzeichnisse in den Project-Settings,
    die ich gefunden habe, auf die Verzeichnisse von VS2005 umgeschrieben.

    Die Mirgation auf VS2008 habe ich allerdings noch nicht probiert. Das wäre der nächste Schritt.

    Kann mir bitte jemand helfen?
    Hatte vielleicht jemand schon das Problem?
    Gibt es eine Lösung?

    0
  • Mod

    Warum machst Du einzelne Schritte? Einmal Hauruck auf VS-2013 und gut ists.

    Ansonsten kann man ohne Codebeispiele hier nichts zu sagen.
    Ich wüsste keinen Bereich in VS-2005 selber, der irgndwo in die COmboboxen eingreift, außer DU hast selbst Code gesubclassed.

    Debug/Release gleiches Problem? Nur um Optimizer Probleme auszuschließen.

    0
  • E

    Martin Richter schrieb:

    Warum machst Du einzelne Schritte? Einmal Hauruck auf VS-2013 und gut ists.

    Ansonsten kann man ohne Codebeispiele hier nichts zu sagen.
    Ich wüsste keinen Bereich in VS-2005 selber, der irgndwo in die COmboboxen eingreift, außer DU hast selbst Code gesubclassed.

    Debug/Release gleiches Problem? Nur um Optimizer Probleme auszuschließen.

    Hallo Martin,
    danke für den Hinweis auf irgendwelche Zwischen-Klassen.
    Und na ja, ... momentan ist die Version 2005 die neuste bei uns in der Firma.

    Ich habe doch eine zwischengeschaltete Basis-Klasse für alle Views gefunden,
    die sowas wie eine Standardisierung machen soll. Das Statement, das dafür verantwortlich ist auch.
    Aber es wäre sicher eine schlechte Idee, das einfach raus zu nahmen!

    Es liegt sicher daran, dass eine COmbo-Box zwei Grössen besitzt.
    Aber unter VS2003 ging es noch!
    Was ist in VS2005 anders? Und wie passe ich das an?

    Hier die verantwortliche Funktion:

    pControl->GetWindowInfo(&sWindowInfo);
pControl->SetWindowPos(NULL,(int)(((ItemRect.left-DialogRect.left)*dMul)+0.5),
				(int)(((ItemRect.top-DialogRect.top)*dMul)+0.5),
				(int)(((sWindowInfo.cxWindowBorders + ItemRect.right-ItemRect.left)*dMul)+0.5),
				(int)(((sWindowInfo.cyWindowBorders + ItemRect.bottom-ItemRect.top)*dMul)+0.5),
				SWP_NOZORDER|SWP_NOACTIVATE|SWP_NOACTIVATE);
    0
  • Mod

    Und Du initialisierst sWindowInfo auch?

    Ansonsten ware das ein Bug Deinerseits.

    0
  • E

    Ich würde sagen, dass es initialisiert ist.
    Wie könnte es anders gehen, als mit:

    pControl->GetWindowInfo(&sWindowInfo);

    Unter VS2003 hat noch alles funktioniert.

    0

  • Lies doch bitte zuerst immer die Doku dazu: GetWindowInfo:

    MSDN schrieb:

    pwi [in, out]

    Type: PWINDOWINFO

    A pointer to a WINDOWINFO structure to receive the information. Note that you must set the cbSize member to sizeof(WINDOWINFO) before calling this function.

    Und den Rückgabewert solltest du auch auswerten.

    0
  • Mod

    elmut19 schrieb:

    Ich würde sagen, dass es initialisiert ist.
    Wie könnte es anders gehen, als mit:

    pControl->GetWindowInfo(&sWindowInfo);

    Unter VS2003 hat noch alles funktioniert.

    Du verstehst es nicht.
    sWindowInfo.cbSizemuss gefüllt warden!
    Hast Du esnun gefüllt? Oder nicht. Wenn es unter 2003 geklappt hat, dann war es evtl. reiner Zuifall, weil der Speicherinmhalt zufällig anders war und es dort gekalppt hat.

    http://msdn.microsoft.com/en-us/library/windows/desktop/ms632610(v=vs.85).aspx

    Wenn Du cbSize nicht gesetzt hast ist es Dein Fehler. Nicht der von VS!

    0
  • E

    [quote="Martin Richter"]

    elmut19 schrieb:

    sWindowInfo.cbSizemuss gefüllt warden!
    Hast Du esnun gefüllt? Oder nicht.

    http://msdn.microsoft.com/en-us/library/windows/desktop/ms632610(v=vs.85).aspx

    Wenn Du cbSize nicht gesetzt hast ist es Dein Fehler. Nicht der von VS!

    Ich habe es, wie beschrieben nun eingesetzt. Es hatte gefehlt.
    Nun rufe ich es so auf:

    sWindowInfo.cbSize=sizeof(WINDOWINFO);
if (pControl->GetWindowInfo(&sWindowInfo))
   pControl->SetWindowPos(NULL,(int)(((ItemRect.left-Di ....

    Es klappt leider immer noch nicht.
    Ich habe in der Zwischenzeit nach einigen Code-Beispielen gesucht.
    Dort sind auch keine anderen Lösungen zu sehen.

    0
  • Mod

    Was sagt dert Debugger. Sind die Werte wenigstens OK?

    0
  • E

    Die Übergabe Parameter habe ich weitgehend getestet.
    Es stehen immer integers zwischen 17 und 580 drin.
    Da dieses "SetWindowPos" in eier Schleife über alle Controls geht,
    die auf dem Dialog sind, weiss ich nicht genau, ob ich auch eine
    der Combo-Boxen erwischt habe. Denke aber schon (nach ca. 20 Durchläufen habe ich abgebrochen).

    Und sobald ich dieses "SetWindowPos" auskommentiere, gehen die Combos wieder.

    Da das Programm mein Vorgänger geschrieben hat, weiss ich nicht mal genau,
    wofür das eigentlich gut ist. Das Aussehen verändert sich für mich nicht erkennbar.
    Das Dialogfenster ist auch in der Grösse unveränderlich.

    0
  • E

    Hallo zusammen.
    Ich hab nun das Problem doch gelöst bekommen.
    Hab lange dafür suchen müssen. Ev. sind immer noch subjektive
    Eindrücke mit dabei, aber es geht nun.

    Letzlich liegt es doch daran, dass der neuere Compiler sich anders
    verhält als der alte. Und das hier durchgeführte "SetWindoPos" auf
    die Controls mit ihrer ermittelten Grösse (siehe oben), hat eine
    weitere Einflussnahme anscheinend auch unterdrückt, wie auch immer.
    Jedenfalls wurde auch versucht, in der OnInitDialog-Methode des
    betroffenen Views, die Grösse der ComboBox durch eine "SetDropDownHeight"-
    Methode zu korrigieren (Unter VS2003 unnötig, unter VS2005 zunächst wirkungslos).

    Dann bin ich in meine BaseDialog-Zwischenklasse gegangen und habe für die
    Controls vom Typ CComboBox die Höhe auf 4 Zeilen gesetzt (nachfolgender Code):

    if(pControl->IsKindOf( RUNTIME_CLASS( CComboBox ) ))
	ItemRect.bottom = ItemRect.bottom + ((ItemRect.bottom - ItemRect.top)*4);

    Diese Änderung alleine hats dann auch noch nicht getan, da der Typ des Controls
    nicht erkannt wurde.

    Nun bin ich in meine Dialog-Klasse gegangen und habe die COmboBoxen
    als public Member und als "DDX_Conrol" definiert. Hierdurch wurde dann erst
    der Typ des Controls in der Basis-Klasse erkannt, und die Grösse wurde angepasst.

    DDX_Control(pDX, IDC_COMBO_VAR1, m_cmbVar1);

    Dass ich die Höhe fix auf 4 Zeilen gesetzt habe hatte keine EInfluss auf die
    tatsächlich angewandt Höhe. Diese hat sich der Anzahl Elemente angepasst.
    BEi 3 Elementen wara sie 3 Zeilen hoch und bei 10 Elementen war sie ca. 6 Zeilen
    hoch, mit Scrollbar.

    Aber nochmals vielen Dank für Eure Beteiligung.
    Das hat mir auch geholfen

    0
  • Mod

    Es ware weitaus einfacher gewesen, wenn Du Dir einfach den Klassennamen geholt hättest. Dann hättest Du nicht für alles Membervariablen einbauen müssen.

    0
  • E

    genau das habe ich ja nun gemacht.
    Aber das scheint nur zu funktionieren, wenn man dieses Control
    als DDX_Control definiert. War jedenfalls hier so.
    Vielleicht ist es beim nächsten Compiler wieder anders.

    Und in meiner zwischengeschalteten Basisklasse CBaseDialog wird dieses
    "SetWindowPos" eben für alle Controls in einer Schleife durchgeführt,
    als Anpassung auf verschiedene Systeme (z.B. auch WinCE). Dazu wurde
    auch "SetWindowPos überschrieben, wie ich eben erst auch herausgefunden habe.

    0
  • Mod

    Nein. Das ist nicht so.

    Den Classname kannst Du immer bekommen.
    IsKindOf kann nur funktionieren wenn Du DDX_Control verwendets. Sonst erkennt das System immer nur ein CWnd.

    0
Anmelden zum Antworten