GUI-Bibliotheken | QTextEdit

[Doktor.]

Hey, ich arbeite momentan für GUI Anwendungen mit Qt, aber für mein aktuelles Projekt ist der QTextEdit anscheint zu langsam um den Text schnell genug anzuzeigen und es dann ab und zu zu crashes kommt(Logge die Packets via. Hook von einem Game).
Daher dachte ich mir, ich schau mir mal andere GUI-Bibliotheken an, aber bevor ich mir jetzt jede mögliche Lib runterlade, frag ich mal lieber welche ihr empfehlen würdet, bzw. ihr nutzt.

Fragen:
- Gibt es eine Möglichkeit das mit dem crashes durch QTextEdit zu verhindern?
- Was benutzt ihr um eure Anwendungen mit einer GUI zu verzieren, bzw. was empfehlt ihr?

Mfg.
Doktor.

[Padmak]

Setzt du den Text des Textfeldes direkt ausm Hook? Dann wäre der Crash nämlich ziemlich einfach und schnell erklärt/gelöst

Ansonsten wäre wxWidgets noch ne Lib die du dir ansehen könntest

Padmak

[Doktor.]

DetourFunc( ( BYTE* )add, ( BYTE* )&func, 14 );

void func()
{
	char* packet;
	_asm
	{
		MOV packet,EDX
	}

		addPacket(packet, 1); //Text in TextEdit ausgeben
}

In addPacket gebe ich den Text in TextEdit aus.
Bin mir grad nicht ganz klar, was du mit "Text des Textfeldes" meinst.

[Padmak]

Naja, ich vermute dass du aus deinem gehookten Thread auf das QTextEdit zugreifst, das darfst du nicht tun. Du musst über Signals/Slots arbeiten und das so trennen.
Falls du das bereits tust, ignorier das und erklär dein Problem genauer^^

Padmak

[Doktor.]

Asoo das erklärt einiges, den genau das tue ich. Werde das mit Signals/Slots mal machen, editiere dann später wenn es ging.

[Padmak]

Eigentlich müsste dir auch Qt andauernd Debugnachrichten in std::cerr schreiben, dass du genau das falsch machst. Könntest dir mal die Konsolenausgabe ansehen (so z.B.: )

Padmak

[Doktor.]

Danke, läuft perfekt. Sogar die Performance in Game ist viel besser dann.

[Logtetsch]

Eine andere Möglichkeit wäre sich das Handle von dem QTextEdit zu holen und dann mittels SendMessage() den Text beifügen. Das kannst du sogar direkt von deinem gehookten Thread aus machen.

[Padmak]

Warum sollte er nicht die von Qt bereitgestellten Methoden benutzen, sondern auf plain WinAPI zurückgreifen?
Das ergibt wenig bis gar keinen Sinn. Vor allem, weil Signals und Slots genau die gleiche Mechanik nur in "schön" sind.

Padmak

[Master674b]

Wie wärs mit nem Dispatcher? Du postet dann einen std:: packaged_task an den UI-Thread und falls dieser was zurückliefern soll kannst du ein std::future zurückgeben.

[Doktor.]

Muss es nochmal hochholen, entweder mach ich es etwas verkehrt mit den Signalen und Slots oder keine Ahnung.
Bevor ich das Signal auslöse und zum Slot gehe ist das Packet was ich habe korrekt, aber sobald ich in der Slot-Funktion bin, ist das Packet, bzw. die Ausgabe verwirrend.
Es werden Zeichen angezeigt, die eig. nicht enthalten sind oder das Packet wird gleich 20 mal ausgegeben, wobei es nur die Hälfte vom Packet ist.

Beispiel:

 Falsche Ausgabe, mit Signal/Slots

7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1

 Richtige Ausgabe, ohne Signal/Slot aber mit Crash

qslot 2 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1

connect(this,SIGNAL(sAddPacket(char*,int)),this,SLOT(addPacket(char*,int)));

void Read::fRecv()
{
	char* packet;

	_asm
	{
		pushad 
			pushfd
			MOV packet,EDX
	}

	if(packet != nullptr)
	{	
		emit pRead->sAddPacket(packet,1);
	}

	_asm
	{
		popfd 
			popad
	}
}

void Read::addPacket(char *packet, int type)
{
    tePacketLog->append(packet);
}

#Edit
Habs jetzt selber behoben, indem ich es vorm emit in ein QString umgewandelt hab, würde mich aber dennoch interessieren warum dies mit einem char* so rumspinnt?

Mfg.
Doktor.

[Padmak]

Spontan würde ich sagen: wenn du einen char* übergibst, der als lokale Variable auf dem Stack erzeugt wurde, solltest du dich vom Ergebnis nicht überrascht fühlen.
Richtig übergibst du es entweder als Heap-Objekt (per new alloziiert, nicht empfohlen) oder wrappst das ganze in einen unique_ptr (oder shared_ptr?) <- sehr empfohlen

Padmak

[MrSm!th]

Spontan würde ich sagen: wenn du einen char* übergibst, der als lokale Variable auf dem Stack erzeugt wurde, solltest du dich vom Ergebnis nicht überrascht fühlen.

Der Pointer wird immer auf dem Stack liegen, das ist auch überhaupt kein Problem Sein Problem ist, dass er keinen Buffer erzeugt, nicht einmal auf dem Stack. Der Pointer ist einfach uninitialisiert.

[Padmak]

Nein, er kopiert ja EDX in den Pointer, also zeigt der Pointer auf 'nen Buffer (vermutlich aufm Stack)
Dass das an sich 'ne ziemlich unsichere und ... naja einfach schlechte Methode ist, ist auch offensichtlich

Padmak

[MrSm!th]

Originally Posted by Padmak

Nein, er kopiert ja EDX in den Pointer, also zeigt der Pointer auf 'nen Buffer (vermutlich aufm Stack)
Dass das an sich 'ne ziemlich unsichere und ... naja einfach schlechte Methode ist, ist auch offensichtlich

Padmak

Achjo, stimmt.
Nein, ein Smart Pointer wäre da absoluter Mumpitz. Wenn er sich den Pointer vom Zielprogramm klaut, kann er nicht einfach Annahmen machen, die voraussetzen, dass er den Pointer besitzt und weiß, wo er verwendet wird, aber genau das tun die genannten Smart Pointer.

Wenn, dann könnte man zu einem weak_ptr greifen, wobei ich gerade nicht weiß, ob der ohne einen shared_ptr existieren kann. shared_ptr ist jedenfalls genau so falsch wie unique_ptr, weil sie den Speicher in ihrem Destruktor einfach freigeben, obwohl sie weder wissen können, womit er reserviert wurde (schonmal nen VirtualAlloc Block versucht zu delete'n?) noch wann sie ihn überhaupt freigeben dürfen.
Dass Stackspeicher sowieso nicht freigegeben werden darf, ist ebenfalls eine Einschränkung, solltest du mit deiner Annahme, es handele sich um einen Pointer auf einen Stackbereich, richtig liegen.

Und ob der Pointer auf etwas auf dem Stack zeigt, kann nur der OP sagen. Selbst dann muss er nicht zwingend sofort ungültig werden, es kommt auf den Stackframe an. Wenn es eine lokale Variable der WinMain ist, die irgendwo bis ins tiefste Level durchgereicht wird, kann er Pointer darauf durchaus nutzen.


Was mir gerade auffällt:
Was sollen die pushad und pushfd Anweisungen? Es wird doch gar nicht schreibend auf die Register zugegriffen. Durch das Pushen der Register verringert sich der Stackpointer (ESP). Im Falle einer cdecl Funktion verschiebt sich dadurch der Zugriff auf lokale Variablen, was der Compiler aber nicht weiß. Somit wird dann falsch auf Packet zugegriffen.
Entweder solltest du den Teil ganz in Asm schreiben, um ungewollte Registerzugriffe zu vermeiden und zu wissen, wo was passiert oder du schreibst ihn ganz in C, außer halt das eine Auslesen von EDX (oder nutzt die fastcall Convention). Dieses sinnlose Pushen von Registern ist jedenfalls ein potenzielles Problem, ohne einen wirklichen Nutzen zu bringen.