Ok, je voulais dire : "je te rajoute au groupe FlexProject sur les ProgBoards ?"

En tout cas, merci de ton inscription ! Et tu as maintenant les droits nécessaires pour crééer/éditer des pages sur le site FlexProject, dont je rappele l'adresse :
http://flexproject.progboards.com

Bonjour !

Pour chaque mot -clé de l'API, il y a un petit exemple. Mais, en regardant la doc de QBasic, je me suis souvenu que certains exemples renvoyaient vers un code plus complet.

Pourrait on créé des nouvelles pages pour créer un exemple assez long et complet regroupant plusieurs mot-clé ? Par exemple, une page contenant un code montrant comment se servir de DATA, READ et RESTORE.

Si la réponse est positive, comment faire ?

Bonne journée.

ps : on doit écrire "mot-clé" ou "mot-clef", je rencontre les deux

Salutations.

Je me suis occupé des API "SELECT CASE" et "CASE".

J'ai fait un API SELECT CASE très détaillé et un API CASE très simple avec possibilité de consulter le premier (lien interne). Je pense que la solution est valable.

Tu pourrais faire de même : READ détaillé, DATA simple, RESTORE également simple avec possibilité pour les deux derniers de consulter le premier (à condition d'y avoir parlé de DATA et RESTORE évidemment).

Mot-clé peut également s'écrire mot-clef (sur le Quillet au mot clé, il est écrit : n. f. V. CLEF).

Salutations.

{AJOUT : tu as bien fait de poser la question : je me suis aperçu que mon lien interne ne fonctionnait pas et je me suis empressé de le rectifier avec [[API_SELECT_CASE]]}

Edité par SFLPMEA ( 28/01/2007 13:14:07 )

Salutations.

Que nous offre le Qbasic comme genre de fichiers ?
1 - RANDOM : Lecture/écriture sur fichier à accès aléatoire (par défaut).
2 - BINARY : Lecture ou Ecriture sur fichier binaire.
3 - Fichiers SEQUENTIELS avec :
- a - INPUT : Lecture seule sur fichier séquentiel.
- b - OUTPUT : Ecriture sur fichier (création initiale).
- c - APPEND : Ecriture à la fin du fichier.
De quelles instructions et fonctions disposons nous pour le traitement ?
- ACCESS. - APPEND. - BINARY. - CLOSE. - CVI, CVS, CVL, CVD, et MKI$, MKS$, MKL$, MKD$. - EOF. - FIELD. - FILEATTR. - FILES. - FREEFILE. - GET. - INPUT, OUTPUT. - INPUT$. - IOCTL et IOCTL$. - LINE INPUT #. - LOCK. - LOF. - LSET et RSET. - OPEN. - 0, I, R, B. - PRINT, PRINT USING. - PUT. - RANDOM. - READ. - SEEK. - UNLOCK. - WRITE. Et je dois en oublier …

Le pôvre novice qui va se lancer dans la programmation des fichiers va devoir surmonter un tas d'obstacles :
Consulter l'aide en ligne de chacun des mots-clés, voir les "détails" et aller en plus sur "Voir aussi" …

Ne serait-il pas plus simple et judicieux de créer 3 API :

-> Fichiers RANDOM.
-> Fichiers BINARY.
-> Fichiers SEQUENTIELS.

Dans chacun d'entre eux, tout serait dit sur le type de fichier, de l'OPEN au CLOSE, et aller se promener dans tous les sens à la recherche d'informations deviendrait inutile.

Petit inconvénient : il y aura certainement redondance, répétition d'informations ce qui sera inévitable.

Ce qui ne supprimerait pas les API d'instructions/fonctions élémentaires.

Qu'en pensez-vous ?

Salutations.

Je n'aime pas trop l'idée de vouloire modifier des fonction traditionnel.
En effet, il faudrais que le langage reste compatible qb donc garder la même syntax semble une bonne idée.
Je ne dit pas pour rajouter d'autre fonction, mais pour celle existante, mieu vaut garder un standard pour garder le langage portable et flexible. J'imagine quelqu'un devant passer de Qb a Flex. Je pense qu'il ne serais pas absolument fabuleu de se dire "oh, vous passez dans un langage basic, mais vous devez reconvertir nonante pourcents de votre code".
Ce n'est pas une critique, mais je trouve que ça ne colle pas vraiment avec l'idée de flexibilité..
Ou alors, peut-être faire des mot-clé alias que l'utilisateur pourais définir lui-même?
Ceci pourais s'appliquer a toute les fonction de FlexBasic.
Pour ce qui est de l'aide en ligne, j'ai commencer avec ça, et je n'ai pas eux de gros problèmes.
Voilà, c'est mon point de vue.
A concidérer comme un avis.

Salutations.

Je pense qu'il y a un malentendu.
Je n'ai jamais dit que je voulais modifier les instructions/fonctions de base du Qbasic. J'ai simplement proposé de les présenter autrement, en les regroupant par type de fichier.

Pour chacun d'entre eux ne seraient proposés que les instructions/fonctions qui leur sont propres.
- Par exemple, GET et PUT ne s'appliquent pas aux fichiers séquentiels et ils ne seront pas présents pour ce genre de fichier.
- De même, PRINT (avec ou sans USING) et READ ne concernent que les fichiers séquentiels et ils ne seront nulle part ailleurs.
- CVI, CVS, CVL, CVD, et MKI$, MKS$, MKL$, MKD$ n'intéressent que les fichiers RANDOM et ils ne seront nulle part ailleurs.

Mon idée est que, pour chaque type de fichier, ne seraient trouvés et étudiés que les instructions/fonctions concernant ce type et rien d'autre.

Si une instruction comme OPEN concerne tous les types de fichiers, elle y sera présente (3 fois) mais aménagée pour le type concerné.

Mais les instructions de base du Qbasic ne changent en aucune façon.

Après ce complément,

Salutations.

Ah oui, d'accord, je comprend ce que tu veux dire, SFLPMEA.

Est-ce que l'un d'entre vous a lu l'exemple de l'instruction GET, en QB4.5?
J'ai adoré. Je ne m'imaginais pas Bill comme ça!

Ca ressemble un peu à une gestion d'espace de noms ou de classe, ton idée, SFLPMEA.
Ce serait une bonne chose, je pense.