Improved Console 3.4

SideWinder

aber die README.TXT konnte ich nicht so gut lesen.

Sollte afaik noch auf 80 Zeichen begrenzt sein, wird aber sowieso mal wieder ein Update erhalten. Was da drin steht ist ja zT nicht mal ordentliches Englisch.

außerdem schreibste .TXT statt .txt, bei .cpp, .hpp und .h stimmt's.

Changed, im nächsten Update passt das. Keine Ahnung warum ich da überhaupt große Dateinamen verwendet habe

meinen lese-geschmack trifft ja eher diese liste

Die Enumeration kann ich ja mal abändern

müßte wohl der harmonie wegen "void normalize ();" heißen"

Hrhr, hab ich auch überlegt. Aber wegen Abwärts-Kompatibilität kann ich wenn überhaupt nur normalize() hinzufügen und aus normal einen deprecated inliner machen der normalize() aufruft - ähnlich setFullscreen/fullscreen. Ob das Sinn macht? Ok, warum nicht.

damit ich immer wiß, ob jetzt mein corsor dran ist oder das window.

Grundsätzlich gilt: Überall wo nichts dabei steht denk dir "Window" hinzu. Sollte ich eventl. dazuschreiben. Ändern kann ich jetzt allerdings am Interface nichts mehr. Da sind wir 0.4 Versionen zu weit

das kannste aber nicht machen. beide string oder beide char*.

Dann wohl beide string.

ungetestet? was passiert, wenn GetStdHanlde mist liefert? oh, alles ist ja ungetestet. ok, wird schon klappen.

Wenn es Mist liefert werden alle Funktionen die darauf beruhen ganz einfach nichs tun. Fehler-Überprüfung gibts in dem Sinn keine. Eventuell sollte ich den User zumindest überprüfen lassen ob das Handle stimmt und überhaupt was funktionieren kann.

Exceptions kommen auf jeden Fall keine, da die Benutzergruppe wohl doch eher blutige Anfänger sind.

naja, bei so viel code muß auch mal gehackt werden. rest war ja super lesbar.

Begrenzt size einfach zwischen 0 und 100, okay werde Kommentar dazupacken.

nimm doch min und max. oder trauste dich nicht, wegen der min-max-makros in der <windows.h>?

Ich mags vor allem nicht weils nicht ordentlich funktioniert. Devcpp glaub ich hat kein min/max oder so. Ich such dir den Thread raus wo die Probleme behandelt wurden, bloß funktioniert die dämlcihe Suchfunktion grade wieder nicht

uih, HWND Console::getCWND() ist ja beeindruckend getrickst. das geht echt nicht normal?

GetConsoleWindow() gibts leider erst ab Win2k/Xp. Vorher muss man das über diesen Dirty-Trick machen (Dafür hat WebFritzi sogar einen Eintrag in die Credits bekommen *g*, er hat das aus einem Sample der WinAPI genommen und nochwas dran rumgebastelt).

Danke auf jeden Fall für das viele Feedback!

MfG SideWinder

masterofx32

Ließe sich die GetCWND-Angelegenheit nicht eleganter lösen indem man mit FindWindow nach der Konsolen-Fensterklasse sucht (ConsoleWindowClass unter NT, tty unter 9x!? ) und dann die durch GetWindowThreadProcessId zurückgegebene PID mit der eigenen vergleicht?

SideWinder

Jeder Prozess kann seine eigene Konsole aufmachen, dann hab ich plötzlich mehrere Aufrufe zu tätigen und jeweils zu vergleichen.

Außerdem hat die MSDN auch diesen Ansatz gewählt - die wissen meistens warum, auch wenn sie es einem nicht erzählen *g*

MfG SideWinder

masterofx32

Dass da möglicherweise mehrere Konsolen verglichen werden müssten ist ja klar, mir erschien es nur trotz des Mehraufwandes eleganter.
Hast du zufällig den Link zu dem entsprechenden Codebeispiel in der MSDN greifbar?

Nutzt jemand "Improved Console" überhaupt?

volkard

SideWinder schrieb:

Ändern kann ich jetzt allerdings am Interface nichts mehr. Da sind wir 0.4 Versionen zu weit

stimmt nicht. kannst locker das interface ändern. am ende noch ne sektion, wo nur inline-einzeiler von alten interfaces stehen. und nach 12 monaten kriegt so ein alt-inloiner __attribute((deprecated)) oder _declspec((deprecated)) dran und weitere 12 monate später wird er gelöscht.
bist also eigrnlich ganz frei. überleg dir nur, was die optimale lösung ist, nicht, warum du sie nicht bauen solltest.

volkard

deprecated schrieb:

Nutzt jemand "Improved Console" überhaupt?

keine ahnung. aber wir schicken jeden nube hin, der nach farben fragt.

masterofx32 schrieb:

Dass da möglicherweise mehrere Konsolen verglichen werden müssten ist ja klar, mir erschien es nur trotz des Mehraufwandes eleganter.
Hast du zufällig den Link zu dem entsprechenden Codebeispiel in der MSDN greifbar?

http://support.microsoft.com/default.aspx?scid=kb;en-us;124103

Aber das ist auf jeden Fall ein riesen Hack.

Vor allen Dingen das:

// Ensure window title has been updated.
Sleep(40);

und sowas findet man in sidewinders code:

std::basic_string<TCHAR> Console::getTitle () const
{
            TCHAR title [512];
            GetConsoleTitle(title,512);

            return title;
}

Und wenn der Titel länger ist?

SideWinder

Aber das ist auf jeden Fall ein riesen Hack.

Wenn die es in der MSDN anpreisen wird das unter Windows aber sicher funktionieren. Selten, dass die dort über ihre geliebte API Unfug erzählen, und offenbar gehts nicht besser

Stimmt nicht. kannst locker das interface ändern. am ende noch ne sektion, wo nur inline-einzeiler von alten interfaces stehen.

Überredet, werd ich einbauen.

überleg dir nur, was die optimale lösung ist, nicht, warum du sie nicht bauen solltest.

*kritzel*, toller Satz

Nutzt jemand "Improved Console" überhaupt?

Ja, ich denke schon. Immerhin wird seit 4 Jahren hier auf der Seite jedem der irgendwie was mit Farben in der Konsole macht diese angedreht. Die Anzahl wird zwar nicht gerade berauschend sein, aber es kostet mich weniger Zeit eine solche Lib zu schreiben und zu pflegen als hier jeden Tag die selben Antworten auf die selben Fragen zu geben *g*

MfG SideWinder

SideWinder

antihack schrieb:

Und wenn der Titel länger ist?

Maximale Größe laut MSDN sind 64KB, ich weiß nicht ob das Sinn macht soviel Speicher für den dämlichen Titel anzufordern?!

Abgesehen davon, dass getTitle() sowieso kaum aufgerufen wird außer intern bei GetConsoleWindow() hat der User eben Pech wenn er es längera ls 512 Zeichen macht.

MfG SideWinder

nimm einfach 64-kb und gut is. auf dem stack geht 512 bytes und 64 kb gleich schnell.

volkard

antihack schrieb:

nimm einfach 64-kb und gut is. auf dem stack geht 512 bytes und 64 kb gleich schnell.

falsch. vor und hinter den 64k sind lebendigar variablen. der speicher wird angefordert. im allgemeinen ist es für den stack viel schneller, ihn beim wachsen dirch page misses immer bis zur obergrenze anzufordern, statt seitenweise. also haben wir gerade 60k speicher gekauft, den wir nicht brauchen. deswegen müssen irgendwo 60k file buffers geschrieben werden. nicht ideal.
aber völlig egal bei bildschirmausgabe, die ist sowas von lahm, da können wir eigentlich machen, was wir wollen.

SideWinder

Ich werde die 64K einbauen, dann kann nichts passieren - irgendwer kommt irgendwann bestimmt noch drauf, dass sein Titel länger als 512 Zeichen haben muss

MfG SideWinder

SideWinder

Update 1 ist nun zum Download verfügbar:

- changes.txt, license.txt und readme.txt updated
- Enumerationen sortiert
- getTitle() mit 64K
- setTitle mit std::basic_string<TCHAR>
- normalize() - normal() nur noch alias
- Kommentare bei den beiden ?:-Unklarheiten

Was ich an Vorschlägen nicht geändert habe (und auch nicht geändert wird) ist der Interface-Change von setXXX() zu setWindowXXX(). Wenn keine Detailangabe gemacht wird ist "Window" implizit gemeint.

Nächster Schritt ist eine C-Version (wenn ich mich dazu aufraffen kann).

Was noch toll wäre
Ich konnte bisher nur mit MSVC 2003 testen, wenn ihr andere Compiler habt wäre es nett wenn ihr mal versucht die Tech-Demo zu compilieren ob da auch alles klappt. Vor allem der DevCpp hat immer Probleme gemacht.

MfG SideWinder

Warum Kommentare bei den Unklarheiten? Schreib doch den Code so das er nicht mehr unklar ist.

Ich würde sagen da gehört eher nen assert hin.

SideWinder

Ich lass das sicher bei einem ?: und mach kein:

const DWORD max_size = 100;

if(size > max_size)
    size = max_size;

Hier gehört eigentlich ein min(size,100) hin, aber das kann ich nicht verwenden. Warum möchte ich euch gerne zeigen aber irgendwer hat den Suchindex wieder mal ruiniert.

MfG SideWinder

Ich verstehe nicht warum du einen falschen Wert wieder gerade biegen willst.

sowas ist auch nicht gut:

typedef CONSOLE_CURSOR_INFO CCI;
typedef CONSOLE_SCREEN_BUFFER_INFO CSBI;