Forumul organizatiei Pontes - www.pontes.ro

Acuma cred ca nu va fi nici chiar atat de grav incat functia GetAppTitle sa dispara sau sa nu mai functioneze, sper ca in prezent acea functie nu lucreaza intr-un mod rudimentar: RouteJAWSToPC, Page-up, SayLine.

Cand am vazut ca Winamp avea in scripturi definita virtualizarea titlului ferestrei la apasarea Insert + T + T, am facut si eu un astfel de script general:
Am setat sa fie apelat cu tasta Insert + T.

Sa vedem daca acesta va mai functiona in Windows Eight.

Intr-adevar, Control + D pentru proprietatile scriptului.

Layout by code este o biblioteca ce permite crearea dialogurilor fara a specifica standard pozitia ocntroalelor, le aranjeaza el automat. Cel putin asa am inteles cand am citit rapid despre el, nici eu n-am folosit. Se pare ca sunt mai multe implementari, pyLbc pentru python, lbc pentru autoIt etc.
O alta rezolvare este folosirea de containere. De exemplu, in .net exista controale inteligente cum ar fi table layout, flow layout care se comporta ca niste tabele, fiecare control ocupa o celula in cadrul lor. Sigur sunt containere din astea si in alte limbaje.

Exact. in alte limbaje au alte denumiri decat containere, si eu am folosit de obicei aceasta metoda fiindca este flexibila. Dar despre Layout by Code chiar nu am inteles cum functioneaza.

Exista Layout by Code si pentru C++?
E destul de greu sa creezi o interfata grafica cu C++ si windows.h, acum am mutat cam tot Quick Reading on Mobile in C++, ma mai chinui doar cu dialogurile pentru setari.
Am zis sa mut totul in C++ pentru a exersa limbajul, de fapt nu limbajul ca el e clar, ci lucrul cu elementele grafice din windows.h.
Mi-a luat ceva timp sa ajung la un meniu clasic, dar am vrut sa reusesc si eu un clasic File, Edit, View, asta dupa ce m-am obisnuit cu limbaje gen AutoIt unde totul e rezolvat sa fie scris in cateva randuri de cod.
Se pare ca nu merita sa fie ales C++ pentru programele simple, decat daca se doreste strict exersarea, cum zicea un coleg azi, trebuie sa fi putin autist sa te apuci sa tot iti bati capul cu C++ cand sunt atatea limbaje mult mai high level, adevarul e ca devin plictisitoare tipuri precum char sau LPSTR si pointerele...

@Manu: Nu confunda limbajul de programare cu biblioteca grafica folosita. Tu ai ales win32 api pentru grafica, care intr-adevar nu e cea mai prietenoasa biblioteca. Sunt multe alte biblioteci care se pot folosi. Chiar WXWidgets de care zicea IonPop e scrisa original in c++ si facuta sa fie folosita in c++. Am mai auzit de qt, care e mai mult decat o biblioteca grafica, iti pune la dispozitie tot felul de functii pentru retea, manipularea fisierelor si tot felul de chestii.

Si biblioteca wxWidgets ofera functii ajutatoare pentru lucrul cu thread-uri, networking, process control, fisiere, functii matematice, lucrul cu string-uri, cu imprimanta, grafica bitmap, data/ora etc.
La fel ca biblioteca QT, wxWidgets este creata tot in C++, insa ambele se pot utiliza pentru a crea programe si in multe alte limbaje de programare.

Poate fi urata si interfata pe care o foloseste o biblioteca, insa de obicei o biblioteca are o interfata asemanatoare in toate limbajele in care se poate folosi, adica foloseste peste tot acelasi mod de creare a obiectelor, cu aceiasi parametrii, doar ca sintaxa depinde de limbajul de programare folosit.
De obicei limbajul de programare este mai urat sau mai frumos, iar limbajul C++ este cu siguranta unul dintre cele mai urate.

Si nu este o problema doar ca este mai urat, fiindca si acest urat/frumos este o chestiune de preferinte. De exemplu, mie nu imi plac limbajele de programare in care trebuie sa retin multe cuvinte in limba engleza, si mai ales atunci cand se folosesc functii sau metode cu denumiri formate prin concatenarea unui numar mare de cuvinte, fiindca intotdeauna uit vre-un cuvant sau care este ordinea cuvintelor. De aceea prefer functii si marcaje scurte, dintr-un cuvant, sau care folosesc diverse semne de punctuatie, doar ca majoritatea considera urat un limbaj cu multe semne de punctuatie, acolade etc.

Problema limbajului C++ este ca este mult prea low-level, adica trebuie sa scri foarte mult cod pentru a crea un program, in comparatie cu alte limbaje de un nivel mai inalt.
Dar avantajul lui este ca este foarte rapid, de aceea este foarte potrivit pentru a crea module de baza, driveri, in care se fac foarte multe calcule si care trebuie sa ruleze foarte rapid, cum ar fi si interfetele grafice.
Dar daca acele interfete grafice in wxWidgets sau QT se pot folosi pentru a crea interfete grafice si in alte limbaje, atunci in majoritatea cazurilor este de preferat sa se foloseasca acele limbaje in locul C++, fiindca interfata va fi mult mai simpla, iar de restul programului... adica ceea ce nu tine de interfata ce sa mai vorbim.
Maestro DEX foloseste de exemplu wxWidgets, dar este scris in Perl. QT nu este inca la fel de accesibil ca wxWidgets, dar in ultima vreme am inteles ca se fac eforturi pentru a deveni mai accesibil.
QT este folosita in programe ca VirtualBox, care nu este extraordinar de accesibil, adica este relativ accesibil, dar apar in el si mesaje de dialog in care nu putem citi decat titlul si nimic si de asemenea am inteles ca si Skype foloseste QT.
Probabil ca in timp va fi imbunatatit, fiindca la fel ca wxWidgets este si QT o biblioteca dezvoltata activ.

Tot ca un exemplu, in Perl biblioteca Win32 API are o interfata extraordinar de simpla si frumoasa, mult mai frumoasa decat wxWidgets de exemplu, insa in ultima vreme nu prea a mai fost dezvoltata fiindca programatorii prefera in general biblioteci grafice care pot rula si pe alte sisteme de operare decat Windows, iar Win32 API are marele dezavantaj ca ruleaza doar sub Windows.

Bibliotecile grafice au de obicei si acele functii ajutatoare de care am amintit fiindca atunci cand se folosesc intr-un limbaj de nivel scazut ca C++, functiile respective sunt foarte utile, fiindca permit de fapt utilizarea unui limbaj de nivel mai inalt, adica se aplica acele functii decat sa se scrie o gramada de cod in C sau C++ care sa faca acelasi lucru.
Cand acele biblioteci se folosesc intr-un limbaj de nivel mai inalt ca Perl/Ruby/Python, acele limbaje au functii interne si module externe de un nivel si mai inalt decat functiile ajutatoare din bibliotecile grafice, asa ca ele nu prea mai au nevoie de acele functii ajutatoare, si in unele cazuri unele dintre acele functii ajutatoare nici nu se pot folosi fiindca in limbajul in care este scris programul exista moduri mult mai simple pentru a face ce fac acele functii si inca exact in acelasi stil in care este scris restul programului.

Oricum, cand vorbim despre accesibilitate, nu conteaza doar cat de accesibila este biblioteca grafica folosita, ci si cat de bine a fost adaptat cititorul de ecran sa lucreze cu ea, or dintre toate bibliotecile grafice, este evident ca JAWS lucreaza cel mai bine cu Win32 API, asa ca daca nu ne intereseaza portabilitatea, Win32 API e o solutie buna.
Pacat insa ca este o solutie veche care nu prea mai este dezvoltata, fiindca firmei Microsoft nu ii place sa tot imbunatateasca, ci mai ales sa tot schimbe, iar in prezent se pare ca inca este la moda interfata Windows Forms folosita in DotNet...
Iar Windows Forms nu este nici ea o biblioteca deschisa ca QT sau wxWidgets, asa ca nu este portabila, si desi teoretic ofera mai multe facilitati in ceea ce priveste accesibilitatea decat Win32 API, JAWS nu lucreaza la fel de bine cu ea.

Vortex, nu confundam, spuneam doar ca scriu in C++, adica cel putin compilez C++, o parte din functii fiind pure C++, o parte fiind cele din Windows Api.
Spuneam ca pentru a crea interfata grafica cu Windows API e destul de mult de scris, cel putin in felul in care se scrie din C++, adica nefiind create wrappers ca in AutoIt. Practic si AutoIt merge tot cu Windows API daca folosesti functiile lor native pentru GUI, dar sunt usor de utilizat fiind de fapt wrappers pe Win32 API.

E adevarat ca sunt si functii care fac sa poti utiliza un limbaj de nivel mai inalt, dupa cum spunea si Ion Pop, practic utilizant Wind32 API simplifici munca atunci cand trebuie de exemplu sa copiezi un fisier dintr-o parte in alta, este functia CopyFile(), in pure C++ ar trebui sa deschid fisierul, sa atribui continutul unei variabile, sa creez alt fisier si sa pun continutul acolo. Am avut nevoie de CopyFile() la Quick Reading pentru Save As, unde dupa alegerea folderului se copiaza de fapt ultimul text convertit dintr-un fisier temp intr-unul cu o denumire noua intr-o locatie noua.

In orice caz, merita sa fie ales C++ pentru invatarea cu greul, apoi orice scripting language va parea foarte usor. Aici macar nu ai split in array si trebuie gasit un algoritm pentru a crea unul, nu poti merge decat cu array-uri de dimensiune prestabilita asa ca trebuie avut grija si calculat tot itmpul dinainte de cate elemente e nevoie, e parca facut sa trebuiasca scormonit dupa algoritmi sau solutii, nu dupa nume de functii etc etc.

@Manu: Te-ai plans de dificultatea utilizarii c++, ai zis de char, de lptr... Astea sunt chestii din win32 api, care nu mai sunt necesare daca folosesti alte biblioteci grafice. Nici macar aia cu array nu e adevarata. In c++ de baza e inclusa biblioteca stl care are obiecte de tip vector, queue si altele. Se pot scrie aplicatii si in c++, eu m-am inteles bine cu el pana am vazut cum are implementata programarea orientata obiect...

@IonPop: da, e greu cu functii lungi in engleza, de aia imi place mie sa lucrez in IDE, ca sa imi completeze el.

Da, ziceam per ansamblu de tot ce tinea de amestecul C++ cu Windows API.
E adevarat, ca se poate rezolva si Array dinamic, ar fi culmea sa nu se poata ceva, din moment ce in C sau C++ sunt create limbajele gen Perl, AutoIt, PHP sau BGT.
Practic se poate rezolva chiar un array dinamic cu pointere, malloc() si realloc, Nu ma gandeam sa ia cineva discutia chiar atat de ad litteram, vorbeam pur si simplu la nivel de comparatie cu un limbaj higher level, dar e bine sa fie clarificate lucrurile, pana la urma vorbim despre programare, nu despre ideile lui Aristotel.
Cand scrii programe in PHP sa zicem si apoi incerci ceva in C++ si vezi ca array-ul cu care esti obisnuit sa poata fi creat din mers la un split, ma rog explode, zici cumva ca trebuie sa definesti un array fix, dar asta nu inseamna ca o fi imposibil sa ai si un array dinamic sau ca nu se poate rezolva problema cu vectors.
Ca sa continuu in spiritul rigurozitatii, C++ are tipul char. E adevarat ca nu e prea necesar daca omiti sa folosesti win32 API, dar el e de fapt un tip chiar de baza avand in vedere ca un string este un array de chars.

Nu stiu ce sa zic despre lungimea numelor functiilor, practic C sau C++ are calitatea de a fi mai putin vorbit englezeste precum se intampla in cazul limbajelor Basic-type, dar e adevarat ca din exemplele in Perl am vazut ca se merge si mmai mult pe semne decat in alte limbaje C-type.

> @IonPop: da, e greu cu functii lungi in engleza, de aia imi place mie sa lucrez in IDE, ca sa imi completeze el.


Mda, doar ca IDE-urile au o si mai mare problema, si anume sunt foarte greoaie si pentru cei care nu au probleme de vedere si nu trebuie sa foloseasca JAWS si ia o gramada de timp ca sa porneasca, si ma refer la Eclipse si Visual Studio, dar pentru utilizatorii de JAWS au si o problema de accesibilitate fiindca au o multime de panouri care pentru a fi folosite trebuie utilizate combinatii dintr-o multime mare de taste, si in plus IDE-urile nu sunt prea utile pentru toate limbajele de programare, ci in special pentru limbajele statice care au alte si alte dezavantaje in comparatie cu limbajele dinamice, dar pana la urma e tot o chestiune de preferinte sau de nevoi...

Apropos de lungimea denumirii functiilor interne si inteligibilitatea lor, PHP este de departe cel mai urat limbaj din cate am vazut eu.
Are functii interne si cu toate literele mici, si cu litere mari si mici (camel case), si cu cuvinte nedespartite de ceva, si despartite de caracterul de subliniere, iar modul in care sunt combinate cuvintele pentru a forma acele functii nu este unul coerent dupa o anumita metoda, ci absolut alandala.
Din acest punct de vedere Perl/Python/Ruby sunt mult mai bune fiindca au functii cu denumiri mai scurte si cu litere mici.
In Python/Ruby insa am vazut moda combinarii cuvintelor fara a le desparti nici prin caracterul de subliniere si nici folosind camel case, si in C la fel, ceea ce pentru vazatori probabil ca nu este o problema mare, dar pentru orbi da, fiindca cititorul de ecran citeste altfel cuvintele daca sunt legate fara spatiu, asa ca acele cuvinte legate sunt mai greu de inteles. In Perl cuvintele se leaga de obicei cu caracterul de subliniere si sunt scrise cu litere mici, asa ca sunt usor de inteles cu un cititor de ecran. Camel case nu este nici el prea prietenos cu cititoarele de ecran, asa ca stilul C#/Java nu imi place, fiindca uneori primul cuvant incepe cu litera mare iar alteori cu litera mica, dar JAWS le citeste la fel asa ca trebuie citite uneori pe litere pentru a fi mai clar.

Pana la urma cel mai bun sistem ar parea sa fie camel case cu un prefix cu litere mici care sa reprezinte tipul returnat de functie, parca hungarian notation era denumit, cel putin pentru variabile aia de la JAWS il prezentau ca fiind avantajos. Deci o mixtura hungarian notation cu camel case.
JAWS ar citi ok intreaga denumire, e mai usor de apasat shift si o litera decat shift si liniuta pentru a face semnul de subliniere.
Cred ca si vizual e destul de greu de citit functii tip C cu toate literele minuscule fara nici un semn de despartire.
Problema PHP-ului mi-am pus-o si eu candva, ma gandeam intr-o vreme ca or fi unele module facute de unii si altele de altii fara sa aiba undeva niste instructiuni clare prestabilite pentru denumirea functiilor.

Hungarian notation este utila doar pentru limbajele puternic tipizate, ceea ce nu este cazul unui limbaj ca Perl sau PHP in care aceeasi variabila poate contine un string, integer, float...

Camel case ar fi OK daca intotdeauna denumirile ar incepe ori cu litera mare ori cu litera mica, dar in limbajele care folosesc de obicei asa ceva nu se intampla asa ceva si in plus am vazut ca Camel case este folosit de programatorii in acele limbaje chiar si in denumirea fisierelor pe hard disk, ceea ce nu este bine fiindca in sisteme de operare ca Windows pot aparea conflicte fiindca literele mari si mici sunt vazute implicit la fel. Si am mai vazut ca acea obisnuinta de a combina cuvintele este de asemenea folosita si in bazele de date SQL, si asta de asemenea nu este prea bine fiindca unele baze de date ca Oracle de exemplu, tin cont de litere mari/mici, asa ca daca creezi o baza de date in MySQL si apoi o portezi pentru Oracle, s-ar putea sa trebuiasca redenumite o multime de denumiri de tabele si coloane daca ele sunt scrise cu camel case, fiindca daca acele denumiri nu sunt incluse intre ghilimele ele sunt considerate de Oracle ca si cum ar fi scrise cu litere mari, pe cand daca se folosesc doar cuvinte cu litere mici unite cu caracterul de subliniere nu apare acea problema.

In Perl se foloseste de obicei Camel case doar in programele care folosesc biblioteci care sunt wrappere pentru alte biblioteci scrise in alte limbaje, cum ar fi Win32 API, sau wxWidgets, daca in bibliotecile originale se foloseste Camel case, pentru similitudine, dar mie nu prea imi place, fiindca in acelasi program pot aparea doua variante de combinare a cuvintelor.

In legatura cu editoarele de cod, am folosit pentru AutoIt editorul cu care vine pachetul de instalare, unul bazat pe SciTe.
Era intr-adevar placut cand la primele litere scrise sugera direct variabila sau numele de functie si dupa apasarea unui enter era scrisa in intregime.
La fel, tot bazat pe SciTe este Notepad++, si el are o multime de pluginuri, e util pentru programare WEB deoarece are si posibilitatea de a salva direct pe server.

Ceea ce e enervant la editoarele acestea, cel putin la toate care sunt bazate pe SciTe, si aici vroiam sa ajung, este ca nu poti selecta cum trebuie o bucata de cod cu JAWS.
JAWS nu citeste ceea ce este selectat, astfel trebuie sa numar de multe ori randurile pe care vreau sa le selectez, apoi sa tin shift apasat si sa numar iar apasarile sagetii in jos pentru a selecta exact ceea ce am vrut.
Exista oare o solutie ca JAWS sa se comporte mai ca intr-un edit normal?
O solutie ar fi Notepad, dar aici nu pot selecta cu control + sageata dreapta sau insert 6 cate o bucatica, sa ii zic lexem si atunci aleg EdSharp.
Imi place EdSharp, JAWS merge perfect in fereastra de editare, se pot si selecta lexeme, dar nu sugereaza completarea automata pentru nume de variabile.

Asadar:
SciTe, Notepad++ ar fi bune dar sunt probleme la selectare,
Notepad ar fi bun dar sunt alte probleme la selectare,
EdSharp ar fi cel mai bun dar nu sugereaza completare automata, cel putin dupa cate stiu eu.

Ce solutii exista? Nu chiar un IDE, un simplu editor.

@Manu: Exact. Am vrut sa clarific, in caz ca mai citesti cineva interesat pe aici, ca nu e neaparat greu de scris interfete grafice in c++, depinde de ce biblioteca grafica folosesti.
Fireste ca char nu e degeaba, dar e mai usor fara el. Si fara structurile alea din win32 api.
Total de acord cu IonPop, php e un fel de amestecatura. La inceput a fost doar o modalitate de contorizare a utilizatorilor,dupa care a evoluat haotic in ditamai limbajul de scripting web. Cam ca si javascript. In ultimul timp se imbunateste situatia, apar framework-uri care au standarde.
La partea cu IDE nu sunt de acord, sunt multi, atat vazatori cat si nevazatori, care folosesc cu succes, printre care ma numar si eu. E drept, eu am o preferinta puternica pentru limbajele strongly typed. Gusturile nu se discuta.
La problema cu scite, am vazut ca cineva scrisese un script pe net care rezolva problema, dar nu a pus sursele. Parca si NVDA are un modul pentru scintilla, s-ar putea sa mearga. Merita incercat.