|
You last visited: Today at 02:01
Advertisement
GUI-Bibliotheken | QTextEdit
Discussion on GUI-Bibliotheken | QTextEdit within the C/C++ forum part of the Coders Den category.
03/08/2014, 19:50
|
#1
|
elite*gold: 0
Join Date: Aug 2011
Posts: 1,190
Received Thanks: 549
|
GUI-Bibliotheken | QTextEdit
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.
|
|
|
03/08/2014, 20:15
|
#2
|
elite*gold: 58
Join Date: Jun 2008
Posts: 2,311
Received Thanks: 8,420
|
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
|
|
|
03/08/2014, 20:26
|
#3
|
elite*gold: 0
Join Date: Aug 2011
Posts: 1,190
Received Thanks: 549
|
Code:
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.
|
|
|
03/08/2014, 21:10
|
#4
|
elite*gold: 58
Join Date: Jun 2008
Posts: 2,311
Received Thanks: 8,420
|
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
|
|
|
03/08/2014, 21:52
|
#5
|
elite*gold: 0
Join Date: Aug 2011
Posts: 1,190
Received Thanks: 549
|
Asoo das erklärt einiges, den genau das tue ich. Werde das mit Signals/Slots mal machen, editiere dann später wenn es ging.
|
|
|
03/08/2014, 22:14
|
#6
|
elite*gold: 58
Join Date: Jun 2008
Posts: 2,311
Received Thanks: 8,420
|
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
|
|
|
03/08/2014, 23:30
|
#7
|
elite*gold: 0
Join Date: Aug 2011
Posts: 1,190
Received Thanks: 549
|
Danke, läuft perfekt. Sogar die Performance in Game ist viel besser dann.
|
|
|
03/09/2014, 00:31
|
#8
|
elite*gold: 192
Join Date: May 2009
Posts: 2,227
Received Thanks: 3,262
|
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.
|
|
|
03/09/2014, 13:51
|
#9
|
elite*gold: 58
Join Date: Jun 2008
Posts: 2,311
Received Thanks: 8,420
|
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
|
|
|
03/09/2014, 14:39
|
#10
|
elite*gold: 0
Join Date: Dec 2012
Posts: 255
Received Thanks: 110
|
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.
|
|
|
03/17/2014, 03:06
|
#11
|
elite*gold: 0
Join Date: Aug 2011
Posts: 1,190
Received Thanks: 549
|
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:
Code:
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1 7.7.-1
Code:
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
Code:
connect(this,SIGNAL(sAddPacket(char*,int)),this,SLOT(addPacket(char*,int)));
Code:
void Read::fRecv()
{
char* packet;
_asm
{
pushad
pushfd
MOV packet,EDX
}
if(packet != nullptr)
{
emit pRead->sAddPacket(packet,1);
}
_asm
{
popfd
popad
}
}
Code:
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.
|
|
|
03/18/2014, 01:11
|
#12
|
elite*gold: 58
Join Date: Jun 2008
Posts: 2,311
Received Thanks: 8,420
|
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
|
|
|
03/19/2014, 18:35
|
#13
|
elite*gold: 7110
Join Date: Jun 2009
Posts: 28,907
Received Thanks: 25,408
|
Quote:
|
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.
|
|
|
03/19/2014, 18:58
|
#14
|
elite*gold: 58
Join Date: Jun 2008
Posts: 2,311
Received Thanks: 8,420
|
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
|
|
|
03/20/2014, 06:55
|
#15
|
elite*gold: 7110
Join Date: Jun 2009
Posts: 28,907
Received Thanks: 25,408
|
Quote:
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.
|
|
|
Similar Threads
|
CSS Server erstellen - 32 Bit Bibliotheken
05/26/2013 - Counter-Strike - 3 Replies
Hallo, wollte gerade einen neuen Server erstellen, muss natürlich die 32 Bit Bibliotheken erstellen, habe also apt-get install ia32-libs eingeben und es hat nicht funktioniert, Google konnte mir auch nicht helfen.
Folgender Fehler kommt:
apt-get install ia32-libs
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Statusinformationen werden eingelesen... Fertig
Einige Pakete konnten nicht installiert werden. Das kann bedeuten, dass
Sie eine unmögliche Situation...
|
Frage zu Bibliotheken
07/25/2011 - General Coding - 5 Replies
So ich hätte da eine kleine (vielleicht auch dumme) Frage.
Wenn ich bei einem Projekt (sagen wie mal was mit Sockets)
eine statische Bibliothek(ws2_32.lib) lade warum muss ich dann noch die Headerdatei winsock einbinden ich meine theoretisch sind doch alle funktionen schon in der statischen Bibliothek deffiniert ?!
Ich freue mich auf Antworten
|
All times are GMT +1. The time now is 02:02.
|
|