Suppression envisagée du switch ASCII dans PB !

[majikeyric]

Fred annonce sur le forum anglais sa volonté de supprimer le mode ASCII définitivement de PureBasic à partir de la 5.40
pour ne gérer que des chaines unicodes.

Ceci afin d'en simplifier la maintenabilité.

http://www.purebasic.fr/english/viewtop ... 14&t=60171

[Fred]

C'est en debat, rien de "definitif" pour l'instant

[nico]

Le problème c'est que le ASCII tu ne peux pas t'en passer pour des requête Web, ce sera quoi la solution dans ce cas?

[Backup]

Fred, il veux faire planter mon EPB ! .. pis c'est tout !

vu qu'il a passé son editeur en Unicode, il nous Snobe

[Ollivier]

Pas d'inquiétude... En contrepartie, Fred va nous rajouter les switchs suivants:

1) Le "CSCII" : Chinese Standard Code International Interface
2) Le "ISCII" : Indian Standard Code International Interface
3) Le "JSCII" : Japanese Standard Code International Interface
4) Le "TSCII" : Thaï Standard Code International Interface
5) Le "BSCII" : Bungali Standard Code International Interface

Bon... Allez je vais me servir un WSCII pour me détendre...

[Fred]

Le problème c'est que le ASCII tu ne peux pas t'en passer pour des requête Web, ce sera quoi la solution dans ce cas?

Exemple de code ?

[Ollivier]

@Fred

Est-ce que cette modif a un impact sur le comportement des fonctions Chr() et Asc()?

[nico]

Exemple de code ?

Oui j'aurais dû préciser, pour des requêtes post dans le corps du message.

[majikeyric]

Quelle sera la taille de ce type de structure en mode unicode only ?

Code : Tout sélectionner

	Structure EnteteModule
		ModuleName.s{16}
		VMajor.a
		VMinor.a
		Size.l
	EndStructure

En ASCII c'est 22 octets, donc j'imagine qu'en unicode 38...
Or c'est typiquement le type de structure que j'utilise conjointement avec un pointeur pour parcourir un fichier contenant diverses informations chargé dans un buffer. Cela permet de tester par exemple le nom du "ModuleName" dans une certaine zone du fichier et les chaines présentes dans ce fichier sont au format ASCII pas unicode...

Donc ça ne sera plus possible dans mon cas de faire

Code : Tout sélectionner

If *enteteModule\ModuleName="C64ROM"

[Backup]

oui, c'est clair que j'espere qu'on pourra toujours acceder aux fichier en mode Ascii
car ça reste encore la Norme ... et pour un long moment

par exemple, il m'arrive d'avoir a analyser certains Fichiers de mon Démodulateur Satellite
il ecrit un index , avec le noms des prg et leur durées ect...
j'aime pouvoir analyser un fichier de ce genre octet par octet (lettre par lettre ) ....

si on passe en unicode, la lecture du ZZ.a ne sera plus un octet .... !!??

[majikeyric]

Je ne sais pas si ton index est juste un fichier texte, mais dans mon exemple c'est un fichier binaire qui est découpé en plusieurs parties qui sont appelés modules et je veux juste tester certaines zones de ce fichier binaire qui contiennent des chaines Ascii.

Il sera toujours possible de lire les fichiers textes ascii par un readAsciiCharacter() ou readstring(fic,#PB_Ascii)... Mais en interne tout sera en unicode.

[poshu]

L'important c'est qu'il s'agit de supprimer le switch du compilo, pas de supprimer TOUTE la gestion de l'ascii de pure; à partir de là tout sera fonctionnel, au pire ça vous fera écrire 3 lignes de code en plus si vous avez ABSOLUMENT besoin d'ascii à un endroit précis.

(et aussi, ça me choque très très fort qu'en 2014 des gens écrivent des programmes non unicode. Vivons avec notre temps, la plupart des langages moderne n'ont même pas connu autre chose que l'unicode: c'est un standard pour le bien de l'humanité <3)

[Anonyme2]

Je ne suis pas pour

Pratiquement depuis le début de mon Projet PureIconManager, je l'ai compilé en unicode.
Le problème, c'est que l'écriture des noms de groupe dans la ressource du fichier (Dll, Icl, groupe identifié '301' dans la ressource) se fait en ASCII, ce n'est pas moi qui ait fixé les règles.

J'ai plus de 150 occurrences d'écriture/lecture en ASCII, j'utilise l'API UpdateResourceA pour mettre à jour la ressource (noms de groupes)

J'utilise le prototype

Code : Tout sélectionner

Prototype.i ProtoUpdateResource_ASCII(hUpdate, *lpName, lpName, wLanguage, Titre.p-ascii, cbData)
GLB_UpdateResource_ASCII.ProtoUpdateResource_ASCII = GetFunction(GLB_kernel32_hLib, "UpdateResourceA")


;// ajoute l'identifiant de groupe 'ICL' et le nom du groupe qui est le nom du fichier sans extension
 If GLB_UpdateResource_ASCII(BeginUpdateResource, #Id_Groupes_PE, 1, MAC_MAKELANGID(#LANG_NEUTRAL, #SUBLANG_NEUTRAL), Chaine_Groupes\s, StringByteLength(Chaine_Groupes\s, #PB_Ascii)) = #Return_Error
;// ferme l'icl en cours sans mettre à jour
EndUpdateResource_(BeginUpdateResource, #True)

...
;// récupère la longueur de la chaine
Longueur_nom_groupe = StringByteLength(NomGroupe\s, #PB_Ascii)

*hModule\GroupNames\s = PeekS(LockResource_Id_Groupes_PE, SizeofResource_Id_Groupes_PE, #PB_Ascii)
                  
;// longueur de la chaine en ASCII
longueur_Ascii = StringByteLength(*hModule\GroupNames\s, #PB_Ascii)
If longueur_Ascii = #Null
       ProcedureReturn #False
EndIf

...
                  If longueur_Ascii > 1
                        *Tampon = PIM_AllocateMemory(longueur_Ascii+1)
                        If *Tampon
                              *Tampon_temp = *Tampon
                              PokeS(*Tampon, *hModule\GroupNames\s, longueur_Ascii, #PB_Ascii)

J'espère qu'on va pas repartir en arrière, certains cas nécessitent l'ASCII.
J'ai pas envie de coder des fonctions pour pouvoir utiliser de l'ascii.
Les protos en ASCII sont pratiques (p-ascii).

[graph100]

comme l'a souligné Fred, si tu compiles déjà en unicode, il n'y aurai AUCUN changements pour toi !

[Backup]

Avec EPB
lorsque je compile en mode normal +debugger (autonome) , tout marche

lorsque je met le commutateur /Unicode et que je compile en mode Avec debugger (F6)

rien ne se lance ... le prg EXE est bien generé , mais il semble que le Debuggeur Autonome de Purebasic , ne veuille pas fonctionner

c'est le meme Debugger en mode normal et Unicode ??