Seite 1 von 1

Probleme bei Rückgabe von QString

Verfasst: 5. Januar 2018 19:35
von cyrano1960
Hallo, ich bräuchte noch mal Eure Hilfe, denn irgendwie verzweifel ich momentan an einer scheinbar total simplen Sache :oops: :oops:

Ich lese über eine DLL Werte von einem externen Gerät ein und erhalte dabei eine unsigned char Array, das ich in einen String mit unterschiedlichen Formaten wandeln möchte. Dazu übergebe ich das Array mit einigen weiteren Parametern einer statischen Methode in einer separaten Klasse. Diese Methode sieht momentan wie folgt aus:

Code: Alles auswählen

QString Configuration::dataToString(unsigned char* chBuffer, int length, int offset){
    QString valueString = "Test";

//    for (int i=0 + offset; i < length + offset; i++)
//    {
//        valueString += valueString.number((int) chBuffer[i], format);
//        if (i < (length -1))
//        {
//            valueString += chSeparator;
//        }
//    }
//    valueString += chTerminator + "\0";

    return valueString;
}
Als der Fehler auftrat, habe ich Schritt für Schritt alles auskommentiert und das ist momentan übrig. Der Aufruf hingegen sieht wie folgt aus:

Code: Alles auswählen

void DataDisplay::on_btnRead_clicked()
{
    QString dataString;
    iReturn = reader->MF_Getsnr(0x52, 0, &snr, chTagID);
    if (iReturn == 0)
    {
        dataString = Configuration::dataToString(chTagID, 4, 0);
        dataString = "neu";
        ui->tagList->append(dataString);
    }
    else
    {
        ui->tagList->append("Kein Tag erkannt");
    }
} 
Die DLL-Funktion "reader->MF_Getsnr()" funktioniert und ich erhalte auch die erwarteten Werte. Ohne Fehler erhalte ich einen Rückgabewert von 0, deshalb springt das Programm auch in die if-Bedingung und sollte dann mit dataToString() den entsprechend aufbereiteten String zurück erhalten.

Das ist momentan natürlich alles auskommentiert, weil ich direkt nach dem Aufruf in eine Exception renne:
QT_Exception.JPG
QT_Exception.JPG (25.48 KiB) 26503 mal betrachtet

Ich habe das Konzept in einem kleinen Testprojekt praktisch 1:1 nachgebaut und da funktioniert es. Die Prototypen sind absolut identisch mit den Aufrufen. Wenn ich den Code Schritt für Schritt debugge, dann ist eine Sache sehr merkwürdig:

Ich springe in die statische Methode und durchlaufe sie auch ohne Probleme, dann springe ich zurück zur aufrufenden Methode und sehe noch die Anzeigen:

dataString = ""
this = Wert: DataDisplay Typ: DataDisplay


Gehe ich dann einen Einzelschritt weiter, was wohl der eigentlichen Zuweisung entspricht, dann erhalte ich:

dataString = <unzugänglich>

Noch zur Info: Ich entwickel auf einem Windows 10 Rechner mit QT5.10 und QT-Creator. Als Compiler nutze ich MinGW und MSVC15. Der Fehler kommt bei beiden Compilern.

Hat jemand eine Idee, was ich hier übersehe??

Re: Probleme bei Rückgabe von QString

Verfasst: 5. Januar 2018 20:15
von Christian81
"length + offset" in der for-Schleife ist sicherlich nicht korrekt.

Re: Probleme bei Rückgabe von QString

Verfasst: 5. Januar 2018 20:36
von cyrano1960
Hallo Christian, warum meinst Du, dass die if-Schleife nicht korrekt wäre? Die arithmetischen Operatoren haben doch höhere Priorität als der Vergleich, also würde er zunächst den Offset zu i addieren und den Wert nutzen, oder?

Aber wie gesagt, das Ganze ist momentan eh auskommentiert, nur die Rückgabe des Strings macht die Probleme. Ich habe valueString auch schon als private statische Variable deklariert, in der Quelldatei dann initialisiert und diese dann in der Method genutzt, aber das Ergebnis ist identisch.

Re: Probleme bei Rückgabe von QString

Verfasst: 5. Januar 2018 20:50
von Christian81
Ich denke dass es falsch ist da die Länge des Inputs wohl length ist und nicht length + offset
Dann ist wohl ui->tagList nicht initialisiert - die Funktion kann so nichts falsch machen.

Re: Probleme bei Rückgabe von QString

Verfasst: 6. Januar 2018 09:15
von cyrano1960
Hallo Christian,

das Input-Array ist vom Inhalt her variabel aufgebaut, mal beginnen die Nutzdaten beim Index 2 mal im 1. Index. Deshalb übergebe ich mit Offset einen Wert, der die Headerdaten überspringt und in den String nur die Daten einliest. Es ist gewährleistet, dass length + offset immer der Länge des Array entsprechen.

Aber momentan tue ich ja nichts anderes, als die Methode praktisch mit Dummy-Parametern aufzufrufen und dem Rückgabe-String direkt die Zeichenkette "Test" zuzuweisen, die dann in der aufrufenden Methode dem TextEdit-Widget übergeben wird. Aber das Programm stürzt immer wieder ab. :?

Re: Probleme bei Rückgabe von QString

Verfasst: 6. Januar 2018 10:39
von cyrano1960
Da bin ich noch einmal. Das Problem liegt wohl doch in einem anderen Bereich und zwar im Zusammenspiel der DLL mit der gui.

1. Rufe ich nur die DLL-Funktion auf und verarbeite die Rückgabewerte direkt in der Methode, in der ich auch den Aufruf durchführe, funktioniert alles problemlos.

2. Kommentiere ich die DLL-Funktion aus und rufe dann die statische Methode zum Konvertieren des Strings auf, funktioniert auch das einwandfrei.

Es kommt also nur zu Problemen, wenn ich in der gleichen Methode sowohl den DLL-Aufruf als auch die statische Methode aufrufe.

Aber ich denke, das können wir wahrscheinlich hier nicht klären, weil mir auch der konkrete Aufbau der DLL nicht bekannt ist und mit welchem Entwicklungssystem die mal erstellt wurde.

Re: Probleme bei Rückgabe von QString

Verfasst: 6. Januar 2018 19:22
von Christian81
Und wo wird chTagID initialisiert? Und wie groß ist snr?

Re: Probleme bei Rückgabe von QString

Verfasst: 7. Januar 2018 11:38
von cyrano1960
Moin Christian,

ich hatte chTagID und snr private in der Klasse DataDisplay deklariert. Jetzt habe ich aber das Ganze noch einmal umstrukturiert und die komplette Funktionalität des Gerätes in eine eigene Klasse gepackt. Dort wird die DLL verwaltet und auch die Umrechnungen durchgeführt. Wenn ich das jetzt mit MinGW compiliere, läuft alles problemlos ab (sowohl im Debug- wie auch im Release-Mode). MSVC macht mir allerdings einen Fehler und zwar direkt bei der Umwandlung des Arrays in einen String:

Code: Alles auswählen

QString Reader::wb_Mifare_GetUID()
{
    QString dataString;
    int iReturn = 0;
    unsigned char buffer;

    iReturn = MF_Getsnr(0x52, 0, &buffer, chTagID);

    if (iReturn == 0){
        for (int i = 0; i < 4; i++)
        {
            dataString += dataString.number((int) chTagID[i], format);
            if (i < (3))
            {
                dataString += chSeparator;
            }
        }
        dataString += chTerminator;
        if (ledActive){
            this->ControlLED(16,1,&buffer);
        }
        if (buzzerActive){
            this->ControlBuzzer(16,1,&buffer);
        }
    }

    else
        dataString = "Kein Tag erkannt";
    return dataString;
}
Ich habe auf die erste Zeile in dieser Methode einen Breakpoint gesetzt. Ist kein Tag vorhanden, wird sie fehlerfrei durchlaufen und die Ausgabe erfolgt wie erwartet. Ist ein Tag auf dem Reader, springt das Programm in die If-Schleife. Wenn ich mir die Daten dann im Debugger anschaue, ist alles korrekt (die Tag-Daten, der Returnwert), aber sobald ich die Zeile:

Code: Alles auswählen

  dataString += dataString.number((int) chTagID[i], format);
anspringe, stürzt das Programm wieder ab. Aber wie gesagt, nur bei MSVC, nicht bei MinGW.

Re: Probleme bei Rückgabe von QString

Verfasst: 7. Januar 2018 11:39
von cyrano1960
Nachtrag:

Wegen Deiner Frage: snr ist nur 1 Byte groß, also ein einzelnes unsigned char.

Re: Probleme bei Rückgabe von QString

Verfasst: 7. Januar 2018 17:14
von Christian81
Und wo allokierst Du den Speicher für chTagId?
Und wird in snr wirklich nur 1 Byte geschrieben?

Re: Probleme bei Rückgabe von QString

Verfasst: 8. Januar 2018 19:06
von cyrano1960
snr ist wirklich nur 1 Byte groß, außer die DLL-Dokumentation stimmt nicht.

Ich reserviere den Speicher für das Array im private-Bereich des Headers der Reader-Klasse mit:

Code: Alles auswählen

unsigned char chTagID[4];

Re: Probleme bei Rückgabe von QString

Verfasst: 13. Juli 2022 13:44
von JAcki32
Christian81 hat geschrieben: 5. Januar 2018 20:15 "length + offset" in der for-Schleife ist sicherlich nicht korrekt.
Würde ich defintiv auch behaupten