PureBasic

Bonjour,

Je sais qu'il est expliqué dans la doc, comment installer plusieurs version de Pure Basic dans des répertoires différentes... Ce qui est parfait... Mais !

Ne serait-il pas plus simple que PB une fois installé, PB considère simplement quand on le lance que son répertoire de base soit
celui dans lequel il se trouve point. Puis...Après, qu'il considère le fichier préférence de son répertoire et forcément toute ce qui va avec et qui l'envoi ou nous voulons...

En plus pour le moment, en exécution des codes, la seule commande qui donne vraiment ou le code se trouve c'est "PureFILE_GetExePath()" de Gnozal, car que ce soit "GetCurrentDirectory_(255, @currentdir)" ou "GetCurrentDirectory()" renvois la plupart du temps le répertoire définit à partir du pref de "C:\Documents and Settings\HP_Administrateur\Application Data\PureBasic"...

ET si on doit utiliser une ou l'autre application dans un autre répertoire d'une autre version... Que l'on en prenne une copie dans
le nouveau répertoire de la nouvelle version. Cela évitera en plus d'altérer l'original... Et de travailler que sur les nouvelle incompatibilité et vraiment vérifier la compatibilité ou non et ce rapidement !

Je sais qu'il y aura des réponse du genre : T'avais qu'a regardé... Ou c'est pas si compliqué... voir autres choses, mais il me semble moi...
Que ma suggestion serait plus simple...

Quand je lançais, QB ou Turbo, et plein d'autres avant ils n'allaient pas chercher ailleurs ou il devait travailler...
Mais évidement c'était du temps de dinosaures...

C'est une question ?

a ma connaissance, un code COMPILLé avec purebasic récupère ses fichiers là ou il se trouve !!


si tu fait "If OpenFile(0, "Test.txt") "

le fichier Test.txt sera recherché a coté de l'application quelque soit le lieu ou se trouve le prg Compilé !!


par contre dans le cadre de l'éditeur le fonctionnement peut être différent !!

perso, je crée un Dossier, dans lequel je sauve d'abord mon code *.pb
comme ça, ça me fait un répertoire de travail

mais il est vrais que Purebasic sans information préalable (que je donne implicitement lors de la première sauvegarde de mon code)

peut avoir tendance a chercher le fichier dans le dossier du compilateur

quoiqu'il en soit voici comment etre sur a tout coup de savoir ou se trouve le prg en cours de codage (même compilé d'ailleurs)

; Donne le chemin courrant du prg
ProgramDirectory.s = space ( #MAX_PATH )
GetCurrentDirectory_ ( #MAX_PATH , ProgramDirectory)
Debug ProgramDirectory + "\"

ne jamais oublier de sauvegarder une premiere fois un code, pour ainsi définir le répertoire de travail !!

je vais peut-être répondre à côté de la plaque parce que je n'ai pas tout compris

mais il est possible de définir dans quel dossier l'IDE ira chercher les codes sources , extrait de l'aide :

Défini le répertoire par défaut qui sera utilisé par les commandes "Ouvrir" et "Enregistrer" si aucun fichier n'est ouvert, ou que le fichier en cours d'édition n'a pas encore été enregistré. Il est conseillé de mettre le répertoire où sont principalement stockés les codes sources.

Pour les préférences, tu peux aussi regarder du côté des commutateurs, notamment /Local.

http://www.purebasic.com/french/documen ... dline.html

Merci de vos réponses et conseils,

Mais ce que j'explique c'est vis à vis de PureBasic lui même quand on installe des versions successives dans des répertoire différents...
Tel que :
c:\00 purebasic\purebasic-394 (Version 3.x)
c:\00 purebasic\purebasic-410 (Version 4.10)
c:\00 purebasic\purebasic-420 ....
c:\00 purebasic\purebasic-430 (Version 4.3 beté 4)
Chacuns avec ses librairies etc...

les fichiers "Pref" de pure basic se trouve dans :
"C:\Documents and Settings\HP_Administrateur\Application Data\PureBasic" renvois vers le dernier installé... Il sufffit d'y changer le "Pref"...

Et il est expliqué dans la doc : "Note: Pour éviter les conflits avec une ancienne version, installez toujours une nouvelle version de PureBasic dans un nouveau répertoire ."

Ou encore comme le dis justement Comtois de le lancer avec /LOCAL, ou /NOEXT voir même /PORTABLE... C'est justement ce que je dis.

D'OU, Ne serait-il pas préférable que lorsque l'on installe une nouvelle version dans un nouveau répertoire (soit un nouveau PB) que l'orsqu'on lance celui là... Il ne tienne compte que du répertoire ou lui se trouve avec ses nouveau "même" répertoires etc... Et donc avec son "nouveau" compilateur, ses plugins et ses nouvelles directives sans tenir compte du tout des autres PB existant sur la machine ?

Certainement que cela prendrais de la place, ou obligerait de copier une ancienne application d'un répertoire d'un autre PB dans le nouveau pour vérifier si elle fonctionne toujours, mais au moins il n'auraient rien en communs et la compatibilité de l'ancien programme pourrais être testé avec certitude... Et validé nouvelle version !

Est-ce que j'ai été plus clair ?

de toute façon j'étais d'accord avec toi

je pense que c'est bête d'utiliser la base de registre ou meme ( "C:\Documents and Settings\HP_Administrateur\Application Data\PureBasic****") pour un programme qui va être en plusieurs version sur un même ordinateur !!

la base de registre (ou dossier system) c'est bien pour 1 prg point barre !


pour Purebasic, ça sert a rien , d'ailleurs c'est même nul, puisqu'on peut en principe mettre purebasic sur une clef USB !!

donc écrire dans la base de registre ou ( "C:\Documents and Settings\HP_Administrateur\Application Data\PureBasic****")
ne sert a rien dans ce cas !!

Ben, oui... Mais en attendant ce truc flanqué ou il se trouve provoque des liaisons entre les versions, puisqu'il garde la trace d'où tu viens quand tu passe d'une version à l'autre à moins de bricoler a chaque fois et par l'IDE les préférences et les "options compilateur"... Ou comme je viens de le faire de créer dans " "C:\Documents and Settings\HP_Administrateur\Application Data\PureBasic\Reserve Pref Version 001" et idem pour chaque version... Au moment de travailler avec l'une ou l'autre on ramène dans le "Root de base" soit "C:\Documents and Settings\HP_Administrateur\Application Data\PureBasic" l'ensemble de la réserve concernée... Ce qui est quand même du travail inutile et pourrait être épargné en ne mettant rien la haut...

ET comme tu le dis aussi ça ne sert à rien... Mais voilà... Ce qui me "tue" sous Windows et pas mal de programme, c'est la LIBERTE que l'on à de cocher des milliers d'options, de paramétrages.. On fait ce qu'on veut quoi ! Mais face au nombre, il y aura toujours une ou l'autre case non lue ou non comprise et donc non cochée (ou décochée)... Et donc les "bugs" qui s'en suivent. Choses qui alimentent des forums trouvant les uns les autres "les conneries de chacun"... Le temps de savoir paramétrer totalement Windows XP et ce que l'on y mets, et sans oublis et Hop, Vista ou Tartenpion est sortis, et rebelotte ! Ce qui permet aussi la sortie de paquets de bouquins, style "trucs et astuces" qui en réalité n'en sont pas, mais issus de mauvaises explications ou encore aux auteurs de cacher leurs bugs derrière des cases à cocher qui ne font strictement rien (Je ne vise personne). Tout comme je ne parle pas de ce forum qui à quand même tendance à construire et aider à construire ce qui mérité une volée de

Moi ce que j'aimerais savoir c'est pourquoi installez-vous plusieurs version de PureBasic en même temps ?

A+
Guimauve

Ben justement... EN principe on développe quelque chose... Et quand une nouvelle version sort il est intéressant et même parfois "obligatoire" de faire évoluer aussi son propre travail... Donc on a l'original qui marche dans la version "n" dans laquelle on l'a crée, puis ensuite on installe la nouvelle version... en laissant les originaux ou ils sont... Et on test si son beau programme fonctionne toujours avec la nouvelle, puis on le fait évoluer avec les nouvelle commandes et tout et tout...

C'est drôle mais j'ai l'impression que vos codes nécessites beaucoup de modification pour passer d'une version à l'autre.

Là ou j'ai le plus de problèmes c'est pour les librairies utilisateurs. À chaque version il faut tout refaire à partir de zéro ou presque. Pour les programmes je lance le compilateur, je regarde comment il réagit et je fais les corrections nécessaires. (C'est pas tellement long 30 minutes au maximum)

A+
Guimauve

C'est un peu vrai ce que tu dis, mais quand il y en à beaucoup... Ou encore justement tellement structuré qu'ils reposent sur plein d'"Include" etc... Ils y a aussi parfois des modifs de PB en quantité suffisante pour que quelqu'un aille même jusqu'à créer "PBSourceConverter.exe" qui convertissait toutes (ou presque) les différences qu'il y avait entre l'une et l'autre version...
Mais il n'y a pas que cela, c'est aussi les nouvelles possibilités, qui font que parfois il faut effectivement revoir entièrement l'un ou l'autre module car cela soulage beaucoup l'ancien code ou apporte beaucoup de fonctionnalité nouvelle à ton propre code impossible avant....

Et ne pas oublier la fainéantise et le grand age, ou il est préférable d'avoir un écran comme Dobro de 22" et de disposer sur l'écran en simultané deux fenêtres l'une avec une version de PB et l'autre avec le nouveau PB tournant tout les deux le même programme en adaptant et améliorant le nouveau en fonction du nouveau, le tout a vue et sans user nos neurones défaillant (Enfin, je parle des miens)...

je garde des anciennes version de pure

uniquement pour les librairies !!

malheureusement on ne dispose pas toujours des sources des librairies !!

et celles-ci ne sont pas toujours a jour ... donc

Dobro a écrit : la base de registre (ou dossier system) c'est bien pour 1 prg point barre !

pour Purebasic, ça sert a rien , d'ailleurs c'est même nul, puisqu'on peut en principe mettre purebasic sur une clef USB !!

Ca marche très bien sur la clef USB, je l'utilise tous les jours au boulot (ou presque pour tester sur un autre OS MS).

Je rebondis sur le sujet ... Répertoire courant ......
**************************************************
Pour bien expliquer et comprendre j'ai crée un répertoire spécifique Pure Basic qui est "C:\0 0 PureBasic\".

Dans ce répertoire crée des répertoires pour recevoir tout ce que je glane sur Pure Basic.... et aussi j'y installe les différentes version qui deviennent :
"C:\0 0 PureBasic\PureBasic394 Forme Brute\PureBasic c'est ici que ce trouve PB 3.94..
"C:\0 01 Pure Basic\PureBasic410 Forme Brute\PureBasic c'est ici que ce trouve PB 4.10..
"C:\0 01 Pure Basic\PureBasic420 Forme Brute\PureBasic ... PB 4.20..
Et enfin : "C:\0 01 Pure Basic\PureBasic430 Forme Brute\PureBasic PB 4.30.Béta 4
-----------------------------------------------------------------
Execption pour la version avec laquelle je travaille principalement actuellement la 4.2 qui à comme répertoire la forme suivante :

C:\0 0 PureBasic\PureBasic >>>>> qui est la base des répertoires attaché à PB. actif et en cours...
-----------------------------------------------------------------
Cette forme devrait me permettre de passer d'une à l'autre sans problème voir même d"en lancer deux différentes dans deux fenêtres différentes... Comme je l'évoque sur un grand écran comme certains

Mais pour cela il faudrait que chaque version dans fenêtre considère SON répertoire de lancement comme étant SA base de travail...
Ce qui n'est pas le cas, car tous font référence à un moment ou un autre aux indications qui ont été placé par la dernière installation soit dans :
"C:\Documents and Settings\HP_Administrateur\Application Data\PureBasic" et au fichiers "*.pref" qui s'y trouvent.

Et les forme de savoir ou on est ci dessous renvois toutes ce que ce fichier "*.prefs" raconte... Excepté la librairie de Gnozal et plus particlièrement : PureFILE_GetExePath() de la librairie PureFILE1 ou 2 ?
-----------------------------------------------------------------
Pour confirmer cela j'ai crée un répertoire "C:\00 Budget 01" dans lequel j'ai placé ce petit test ci-dessous de même qu'il existe dans tout les répertoires cité ci-dessus. (en haut) Alors que mon répertoire de travail normal est :
"C:\0 01 Pure Basic\PureBasic\0 0 0 Partie strictement personnelle\0 0 0 Base Travail en cours\0 Aplication Principale BUDGET\"

Lorsque j'éxecute ce programme ci dessous dans chaque répertoire il me rend invariablement :
"C:\0 01 Pure Basic\PureBasic\0 0 0 Partie strictement personnelle\0 0 0 Base Travail en cours\0 Aplication Principale BUDGET\" Sauf PureFILE_GetExePath() qui me donne chaque fois le répertoire ou il se trouve et même "C:\00 Budget 01" quand il s'y trouve pendant que les autre restent sur leurs positions....

SAUF si on change l'option du répertoire de base dans "Options du compilateur" et "Compiler/exécuter" le répertoire courant.

Mais attention, si l'on a une deuxième fenêtre ouverte, et qu'on la lance alors qu'elle pointe vers un autre répertoire courant Et lorsqu'on revient dans la première fenêtre il faut rechanger les option du compilateur...

Ce qui N'EST PAS LE CAS AVEC la fonction Gnozal ???? La raison est toujours cette référence unique dans "C:\Documents and Settings\HP_A....etc"
------------------------------------------------------------------------------------
Donc je maintient donc que quand une version PB est installé dans un répertoire avec tout ses sous répertoires et ce qu'on lui adjoint, ses librairies, plugins etc...
Il Doit-être totalement indépendant des autres versions en ne référents qu'au répertoire ou il a été installé. ET DONC !

Ce qui permet de voyager n'importe ou dans ses répertoires et de charger n'importe qu'elle source (pb) ou qu'elle se trouve, la faire fonctionner là !
ET QUE pour cela "le GetCurrentDirectory()" DOIT rendre l'endroit ou l'exécution se produit COMME PureFILE_GetExePath() (jusque version 4.2) tout comme son nom le dit "CURRENT" et non pas un endroit ou il aurait été initialiser on ne sait ou comme c'est le cas maintenant.

Pour tester plusieurs forme d'appel : Et changer de répertoire sans modifier quoi que ce soit...

@GeBonet : PureFILE_GetExePath() utilise GetModuleFileName_() et non pas GetCurrentDirectory_ ().

GetCurrentDirectory_ () ----> répertoire courant [ MSDN : "Retrieves the current directory for the current process." ]
GetModuleFileName_() ----> chemin de l'exécutable [ MSDN : "Retrieves the fully-qualified path for the file that contains the specified module. If module handle is NULL, GetModuleFileName retrieves the path of the executable file of the current process." ]

L'équivalent PB de GetCurrentDirectory_ () est GetCurrentDirectory(), l'équivalent PB de GetModuleFileName_() ne semble pas exister ?

Voici le code qu'il te faut :

oui, ou plus simple :
ca te donne le répertoire ou est l'exe
et zou !
(attention, pour tes compilations, mets bien l'exe temp dans le meme dossier que la source)