Je bosse dur, au point que je vais devoir même en montrer un bout ! Je me heurte à un problème de syntaxe récurrent sur des concaténation de chaine pour les afficher dans des objets textes… Je passe l’algorithme et les croisements de sources, je vais poster un truc brut de coffrage…
Si je décompose chacun des morceaux de cette imbrication, je récupère bien les valeurs que je veux, MAIS tout mis bout à bout comme ça ne marche pas ! J’ai pourtant la même syntaxe avec un truc similaire ou je vais taper dans les variables globales et ça marche (en gros du GlobalVariableString() en lieu et place du VariableString())… je ne m’explique pas ce tatonnement systématique par lequel je dois passé.
Bon j’avoue que c’est tordu au milieu au milieu de faire des ToString(Variable()) plutôt qu’un VariableString(), mais d’expérience ça “marche mieux”, donc bon j’aimerais avoir une correction et un guide de bonne conduite sur ce genre de cabrioles, car je bloque des fois des longues et précieuses minutes dans mes affaires…
Mon bout de code me retourne 0 au lieu d’un texte… Je ne sais pas comment ça se passe à la compilation mais dans le cas d’une concaténation je ne pense pas que récupérer la valeur d’une variable ou du texte d’une variable soit si “important” dans mon esprit de scripteur, je veux juste un ****** de chiffre ! Je maudis les mecs qui inventé le typage de variables !
Un correcteur dans le coin pour cette affaire ? Ca doit etre tout ***, j’aurai probablement trouvé la solution d’ici à ce qu’on me propose une réponse, mais j’ai besoin limite d’un cours sur le sujet!
haa… je peux pas désolé, autant j’ai envoyé à 4ian une version compilé de mon projet juste pour avis sur les orientations, autant je peux pas lacher la source, j’ai passé bcp trop de temps sur l’affaire… Je pense que tu peux comprendre, une affaire de sacro saint droits d’auteur /D (même si sans toi y’a bcp de choses que je n’aurais pu faire, je dois bien l’avouer !).
Les variables existent, toutes ! Toutes les valeurs que j’appelle existent dans les événement en amont…
Je construis des variables structures à la volée en récupérant des valeurs dans des fichiers xml pour faire une “base de données internes” dans des variables structures, là je tape que sur de l’assignement de valeurs… j’ai des “jointures” bien plus chiadées dans les conditions… mais bon voilà, le bout ci-dessus… décomposé il marche… concaténé comme ça, ça marche pô
Dans ce cas, tu refais un mini-exemple avec l’expression dedans (et les variables autour avec des valeurs arbitraires) juste pour tester. Parce que j’ai franchement la flemme de chercher directement sans jeu d’exemple…
C’est dingue je comprends pas toutes les valeurs existent…
La chaine complete une fois les valeurs récupérées devrait donner ça : VariableString(s_classe_canon.classe_1.nom)
Et en dur ça marche ! ça me retourne bien laser…
ça ça me retourne “3” :
VariableString(s_items_table.compteur_parsing_xml)
Ce qui permet à ça de me retourner “1” :
VariableString(s_items_table[“item_”+VariableString(s_items_table.compteur_parsing_xml)].type)
Ce qui devrait me donner au final “VariableString(s_classe_canon.classe_1.nom)” pour l’expression complete :
VariableString(s_classe_canon[“classe_”+VariableString(s_items_table[“item_”+VariableString(s_items_table.compteur_parsing_xml)].type).nom)
Mais non… En demandant le nom en dur VariableString(s_classe_canon.classe_1.nom) l’objet texte m’affiche bien le nom en texte que je veux (dans le cas présent… tintintin… un “canon laser” !).
Je comprends pas, c’est pas un problème ailleurs, c’est ma concaténation qui merdoie…
On a pourtant pas de limites d’exécution sur les scripts ou de parenthèses ?
EDIT :
Han… je teste de suite…
Tiens une super suggestion ! => coloré les crochets ouvrant fermant à la façon des parenthèses, en rouge notamment si c’est pas fermé…
hlalala Victor t’es une bête, je ne compte plus le nombre de fois que tu m’as sorti de bourde pareille… 3h que j’étais là dessus…
Bon je pense que tout le reste de mon propos t’illustre une chose : ma suggestion de variable de script… au moins ça éviterait les imbrications à rallonge…
A defaut l’autre suggestion est bonne aussi sur la coloration des [] à la façon des parenthèses… et un check supplémentaire sur l’éditeur d’expression… Je rédige ce genre de truc à longueur de journées mais là je suis passé à coté, fatigue, mais aussi parce que je fais trop confiance au controleur d’expression qui me disait “pas d’erreurs”.
Où ScriptVariable(tmp) = VariableString(s_items_table[“item_”+ToString(Variable(s_items_table.compteur_parsing_xml))]
De la même façon qu’en Php on s’amuse pas à recopier/coller 500 fois des requêtes MySQL, on les décompose sous forme de variable pour en simplifier l’écriture… En passant par des variables déclarées à la volée on se retrouve à pouvoir écrire des requêtes à rallonge comprenant des jointures sous la forme de concaténation de quelques variables.
il est vrai qu’une fois que ma concaténation à rallonge existe ça revient au même, mais quand tu dois l’utiliser 50 fois en appelant des paramètres différents alors qu’une partie de l’expression reste similaire, c’est quand meme plus convivial d’en écrire moins.
Actuellement je peux déjà le faire avec des variables d’objet/de scene/globale, mais seulement voilà cette variable n’a pas besoin d’avoir cette portée : sur un objet c’est douteux, sur la scene, pourquoi faire ? la variable ne me sert que dans une conditon. Globale ? A quoi bon, pour les memes raisons que sur la scene.
Bref je sais pas je sais pas si je suis clair, mais je te jure que tu verrais la tronche de mes conditions d’événements, c’est très très moche à l’écran… je me retrouve avec des trucs à rallonge, mais alors à rallonge…
Je maudis les mecs qui inventé le typage de variables !
