Improved Console 3.4

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;

volkard

;-9 schrieb:

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

ich auch nicht, jetzt wo du's sagst.

Was soll der zweite Parameter bei keybd_event?

In der Hilfe steht:

bScan
This parameter is not used.