Truc super pratique en VB fo se tapper les raccourcis (HotKey) à la main ds les événement OnKeyUp
 
Aprés on dit qu'on peut faire des applications rapidement    
Pas d'équivalent au TActionList de Delphi
Fo tout se farcir à la main
Gestion des messages windows innexistante
Gestion des erreurs Goto syle
Portabilité de l'exe nulle
Lenteur d'éxecution
Gestion des types lamentables
 
Delphi powa

D'après la doc, seul le menu (visible et enabled) permet l'attribution de shortkeys.  Du coup, c'est vrai, ça le fait pas beaucoup  
 
Question portabilité, j'ai ici une applic de 4MB bien lourde qui tourne sous tous les windows (sauf CE) sans modification
 
Question lenteur, 2 possibilités: changer de langage (clairement, dans mon cas, je suis pour, faut juste que je me débarasse d'un client pas fiable) ou utilisation intensive de l'API win32.

drasche a écrit a écrit :   Question portabilité, j'ai ici une applic de 4MB bien lourde qui tourne sous tous les windows (sauf CE) sans modification

une appli de 4Mo en VB ?
t'as pas un seul OCX ou une seule DLL ?

G oublié l'interface aussi elle sucks
 
Ils ont 10ans de retard sur Borland...

J'oubliais aussi les unités de mesure à la con  

 
Plein de dépendances, oui, y compris des trucs développés par le client (en VB   ) mais sinon on produit le seul executable.

[SDF]Poire a écrit a écrit : J'oubliais aussi les unités de mesure à la con

 
Là au moins on peut choisir, mais j'ai préféré garder les twips, pour le moment.  En VB.NET ils ont tout changé  

drasche a écrit a écrit :     Plein de dépendances, oui, y compris des trucs développés par le client (en VB   ) mais sinon on produit le seul executable.

C relou quand même les dépendances...  

drasche a écrit a écrit :     Là au moins on peut choisir, mais j'ai préféré garder les twips, pour le moment.  En VB.NET ils ont tout changé

Avec Delphi C uniformisé C le pixel mais on peut convertir en mm
 
C quoi l'avantage d'avoir le choix entre 15 unités de mesures ? C lourd....  
 
G pas encore l'occasion de regarder tout ce qui est .NET
 
 

[SDF]Poire a écrit a écrit : G oublié l'interface aussi elle sucks   Ils ont 10ans de retard sur Borland...

Elle est tres bien l'interface, je vois pas du tout ce que tu lui reproches, elle est tres bien    
 
P.S.bon, c'est fini ce troll ? on dirais du vazkor tout craché  

mareek a écrit a écrit : Elle est tres bien l'interface, je vois pas du tout ce que tu lui reproches, elle est tres bien       P.S.bon, c'est fini ce troll ? on dirais du vazkor tout craché

T'as regardé l'interface de Delphi ?
 
Oui j'admet C un peu un troll mais ça m'ennerve que beaucoup de boites utilisent ça

delphi non, mais j'ai déjà utilisé jBuilder et C++Builder, j'imagine que c'est similaire.
 
On peut faire à peu pres tous les reproches du monde à VB, mais l'interface est un des seuls trucs agréable du logiciel (avec le debuggeur qui est vraiment bien foutu aussi).

je parlais en comparaison de celle de Delphi ya un debugger aussi

[SDF]Poire a écrit a écrit :   je parlais en comparaison de celle de Delphi ya un debugger aussi

ben je croyais que tous les produits borland était tres proches, seul le langage changeait, on m'aurait menti

mareek a écrit a écrit : ben je croyais que tous les produits borland était tres proches, seul le langage changeait, on m'aurait menti

pour JBuilder oui
 
pour BC non mais ça dépend de ta version

je préfère l'interface de VB (bien configurée evidemment) alors  

mareek a écrit a écrit : je préfère l'interface de VB (bien configurée evidemment) alors

Chacun ses goûts

pour ce qui est du debugger VB, c'est vrai que son indéniable avantage est de pouvoir touiller le code, faire des appels, à peu près tout ce que tu veux...  (tu peux pas sauver par exemple, ça c'est très dommage).
 
En VB.NET, c'est fini.  Comme ça compile pour du vrai, le debugger revient au même niveau que n'importe quel autre.

euh je vois pas ce que le debugger a de + que celui de Delphi qui compile réélement  

VB6 compile aussi, pourtant le debuggeur fait tout ce que tu racontes.  
 
Tu peux plus lancer ton prog dans VB.net avec les points d'arrets, les espions, etc  ?

[SDF]Poire a écrit a écrit :   euh je vois pas ce que le debugger a de + que celui de Delphi qui compile réélement

troll

Beh oui mais vérité aussi
le troll C depuis le début hein....  

[SDF]Poire a écrit a écrit :   Beh oui mais vérité aussi le troll C depuis le début hein....

non, c'est un gros mensonge sur le coup, VB6 compile pour de vrai (même si le compilateur est vraiment nul)

VB6 compile rien du tout.  Renseignez vous un peu.  C'est du semi-interprété et le debugger le tolère dans la plupart des cas.  C'est pour ça que la vitesse d'exécution est bien moindre qu'avec un vrai compilateur.  Pourquoi crois tu que tu peux modifier ton code et même créer de nouvelles fonctions le tout au runtime?  Tssss.

  pas de gros mensonge ptet un tout pitit mais rien de +  

Voilou  

Et déplacer la ligne d'execution en run time sur un point d'arret ? (C le seul truc imposible avec Delphi)

Sources ?
 
le moment où je peux modifier mon code, c'est quand je l'excute en mode debug dans VB (effectivement c'est de l'interpreté dans ce cas), pas quand je lance l'executable sous windows.

la seule chose que tu ne peux pas faire, c'est changé la déclaration des variables globales ou des variables de la procedure en cours, tout le reste est permis.

on parle bien du mode debug depuis le début non?  moi oui ;-)
 
L'exe n'est pas du vrai code exécutable et je peux t'en donner une preuve.  Dans l'exécution de notre application de développement (je l'ai aussi testé dans plusieurs autres), le pointeur d'exécution ne passe que maximum 2% du temps dans l'exécutable lui-même, le reste est partagé entre le runtime VB et les DLL système.  Pourtant, l'application fait énormément de calculs et de tests, donc on va pas me dire que ça se passe dans l'API.  Le runtime est là pour interpréter l'exe.  Pour les mesures, j'utilise TrueTime.

pq pas l'api avec GetTickCount ?

je testerai au boulot pour voir.
 
au fait, t'as bien coché la bonne case dans l'onglet compilation des propriétés du projet ? (non, je dis ça au cas où   )

TrueTime est une merveille, il compile ton application avec des appels à lui pour mesurer le temps d'exécution de chacune de tes lignes de code.  Après, il te fait un rapport complet, et tu sais rapidement où le CPU passe le plus de temps (en millisecondes ou en cycles CPU).

mareek a écrit a écrit : je testerai au boulot pour voir.   au fait, t'as bien coché la bonne case dans l'onglet compilation des propriétés du projet ? (non, je dis ça au cas où   )

 
On compile en mode natif par défaut.  Mais d'après l'expérience de certaines boîtes, il y a des gens qui conseillent de compiler les applications complexes en P-Code car plus rapide dans ces conditions là.  Là, j'avoue n'avoir jamaias vérifié.  Le premier impact visible est la taille de l'exe qui s'en trouve divisé par 2.

je fais les tests lundi et je reposte dans ce topic pour confirmation

tiens c'est vrai que j'attends toujours le résultat de ces tests
 
ce topic est tellement vieux que j'avais plus de drapal dessus

 
c'est un consours de circonstance
 
 
ANTP a fermer un topic en mettant un lien vers un autre qui contenant dans son en tete ( sujet a lire) celui ci...