Demandes d'améliorations sur des composants NSBASE déjà existants
NSBase is a database management system.
Brought to you by:
neuts-jl
Menu
▾
▴
Ce fil est destiné à accueillir des demandes d'amélioration ou de modification de composants NSBASE déjà existants.
Bonjour,
L'assistant ComboBox permet de choisir une source de donnée. Outre l'interface de définition, Il génère une fonction générique pour définir une requête de remplissage de la liste de choix et implémente le remplissage de la liste de choix concernée.
Il serait assez souvent trés utile de pouvoir restreindre la taille de la liste de choix.
La possibilité d'ajouter une clause where portant sur tel ou tel champs de la source de donnée pourrait elle être ajoutée à l'assistant ComboxBox ?
Nb. Sans être exactement identique, cette demande est trés proche de celle visant à pouvoir disposer d'un assistant permettant de définir simplement un QBE pour un formulaire ...
Merci, Cordialement,
Il sera impossible de faire un wizard qui répond à tous les besoins. Par contre le solution actuelle est ouverte, rien de ne vous empêche d'adapter cette fonction à vos besoins
C'est précisemment ce que j'ai fait .... je ne me suis pas interdit de modifier le code SQL figurant dans la fonction générée par l'assistant . J'ai même ensuite modifié la fonction pour qu'elle permette d'inclure une clause where minimaliste... un champ, un opérateur logique et une valeur ...il n'en faut pas plus pour satisfaire beaucoup de besoins... car il s'agit juste de limiter une liste de choix.
A mon sens, un RAD doit permettre de simplifier, de systématiser certaines taches en dispensant le développeur de devoir coder pour un besoin reccurent. Définir une liste de choix grace à un assistant constitue un exemple typique. Pourquoi donc ne pas faire en sorte que cet assistant offre un supplément de souplesse avec la prise en compte de la clause where ?
Je ne refuse pas de coder mais je préferre le faire pour des besoins non triviaux, plus cruciaux que le remplissage de listes de choix.
La version 1.5.1 en permettant de choisir une vue à partir de l'assistant ComboBox resoudra mon problème...mais je ne trouve pas absolument opportun de devoir créer une vue pour ce type de besoin.
En fait l'amélioration de l'assistant, contrairement à ce que j'ai pu laisser penser dans ma demande initiale ne doit pas avoir pour but de créer un QBE universel. Je suis d'accord avec vous c'est complètement hors sujet voire impossible.
L'amélioration, si vous y consentez, pourra simplement être réalisée par une zone de saisie permettant de renseigner les éléments de la clause where tel que cela serait écrit en SQL (Ex : where VILLE = 'PARIS' ) . Il est éventuellement possible de raffiner en proposant le choix du champs et de l'opérateur... mais à ce stade de définition de la requête on peut faire le pari que le développeur saura écrire sa clause where.
Merci d'avance, Cordialement,
Last edit: BARRAL Philippe 2020-02-04
Permettre à l'assistant ComboBox et/ou au composant ComboBox de gérer une liste de valeurs d'affichage et une liste de valeurs de stockage.
Le but est d'afficher des codes et le libellé associé et de stocker dans la table réceptrice uniquement le code. (ex : affichage => itemsA = "2020A452 - GOUACHE BLANCHE 50ML" et stockage => items = " 2020A452" )
Actuellement le composant ComboBox comporte une propriété (items) qui sert tout à la fois à l'affichage des valeurs de la liste de choix et au stockage de la valeur choisie dans le champs de la table réceptrice.
Cette amélioration, trés utile pour la sélection de valeurs correspondant à des codes, est elle envisageable ?
Merci, cordialement,
Bonjour,
Il n'y aura pas de V1.51. mais une V1.6.0 car j'ai rajouté :
- le mode multi colonnes aux combobox et listbox pour repondre à votre besoin ci dessus
- la possibilité d'accéder au requêteur(QBE) à partir de l'assistant de liste...
Super!
j'ai hate...
Merci ( ﾟ◡ﾟ)/
J'ai testé et voici quelques remarques :
OK et "trés bien" pour le choix "à partir d'une requête spécifique à ce composant"
C'est exactement ce qu'il fallait ... du moins ce qu'il me fallait
??? pour le choix " à partir des valeurs de un ou plusieurs champs d'une requête existante"
Cet intitulé laisse supposer que l'on pourra choisir les champs souhaités
Or il il n'y a pas de choix de champs et ce sont tous les champs de la vues qui sont affichés dans la liste
Il faut donc indiquer une vue spécifiquement prévue pour la liste. Pourquoi pas, cela ne me choque pasexcessivement ... mais alors il faudrait modifier l'intitulé
Pour voir si l'on pouvait indiquer des champs précis, j'ai essayé de passer du code SQL dans le paramètre "datasource" de la fonction loadComponentListFromDatasource(datasource,component) ... Cela ne marche pas et génère une erreur ... il faut dire que j'ai passé directement la chaine de caractère correspondant à la requête sans instancier un dataset ... car cela est fait dans la fonction ...
J'ai donc finalement créer une vue dédié à ma liste de choix. A cette occasion j'ai fais deux constatations concernant l'inter face de création de vue :
Elle comporte désormais une case à cocher "Masqué" dont on devine facilement l'utilité
une liste "Catégorie" avec 2 choix vide et le choix "ForCode" dont l'utilité est plus mistérieuse
Ces deux options ont elles un lien avec le choix "à partir d'une requête spécifique à ce composant" des options des assistants liste ? Il semblerait bien car en choisissant une vue pré existante j'ai observé une vue manifestement dédiée à une combox précise d'un formulaire.
"pour le choix " à partir des valeurs de un ou plusieurs champs d'une requête existante"
Cet intitulé laisse supposer que l'on pourra choisir les champs souhaités => ok, il sera changé
Pour voir si l'on pouvait indiquer des champs précis, j'ai essayé de passer du code SQL dans le paramètre "datasource" de la fonction loadComponentListFromDatasource(datasource,component) ... Cela ne marche pas et génère une erreur ., cette fonction utilise l'API "nsbase.application.getSQLFromDataSource("datasource")"
on lui passe en paramétre le nom de la vue ou de la table
*Elle comporte désormais une case à cocher "Masqué" dont on devine facilement l'utilité
une liste "Catégorie" avec 2 choix vide et le choix "ForCode" dont l'utilité est plus mystérieuse
*
Tous les objets (table,vue,formulaire,rapport,script globaux) ont maintenant ces 2 nouvelles propriétés : Catégorie et masqué qui permettent de personnaliser le rangement de ces objets/via un nouveau bouton dans l'explorateur
La categorie "ForCode" permet de ranger les vues dédiées aux listes des formulaires.
Modification de la fonctionnalité d'affichage des colonnes d'une table
L'affichage natif d'une table dans NSBASE permet de sélectionner ou déselectionner, à la volée, telle ou telle colonne. Actuellement ce choix est incommode car il faut le faire en relançant la fonctionnalité de choix pour chaque colonne ... dans le cas d'une table avec de nombreux champs cela devient vite fastidieux ...
Serait il envisageable que la modification de l'affichage des colonnes se fasse en lancant une seule fois la fonctionnalité de choix des colonnes puis en permettant des sélections consécutives de plusieurs colonnes ?
Cela pourrait il également être envisagé pour les DBGrid ?
Merci, Cordialement,
Last edit: BARRAL Philippe 2020-02-22
En attendant, vous pouvez utiliser une vue simplifie de la table
Je reparde pour améliorer cette fonctionalité. Pour info l'affichage natif des tables, vues utilisent le même composant que dans les formulaires : le DataGrid
C'est ce que j'avais résolu de faire.
Bonjour,
Pouvoir modifier les constantes de présentations des formulaires et rapports et pourquoi pas d'autres composants comme par exemple les polices (tailles, couleurs, chasse ...) des labels, des zones, des boutons ...
Je reviens sur cette demande ancienne qu'il me semble plus pertinent de placer dans ce fil de discussion sur les améliorations de composants déjà existants et pour laquelle vous aviez envisagé "d'etudier ce besoin" https://sourceforge.net/p/nsbase/forum/general/thread/bf4af8aa/#c8db/4b4a
Manifestement, NSBASE en mode développement semble faire usage de constantes pour ce qui concerne la création des formulaires et des rapports. Par exemple la taille général du formulaire, la taille la couleur, la hauteur ou la police des Panets "Top et Bot" ...
Cela serait intéressant de pouvoir y accéder pour les modifier et définir ainsi des constantes de présentation permettant d'avoir une interface homogène et personalisée dans tous les formulaires et rapports que nous créerions pour les besoins de nos applications. Cela ferait également gagner du temps et permettrait éventuellement de changer globalement d'un seul coup certains éléments de présentation ... Cela peut même, pourquoi pas déboucher sur des modèles de présentations enregistrés ...
Pensez vous pouvoir fournir cette facilté de développement ?
Merci, Cordialement,
Bonjour,
Adoption d'un ordre de tri unique pour la présentation de l'ensemble des composants dans l'interface de développement de NSBASE.
J'ai vu que recemment l'ordre de présentation des formulaires, rapports était devenu alpha bétique. C'est une trés bonne idées . Pourrai elle s'appliquer à d'autres listes de choix de l'interface de développement comme par exemple le choix des datasources ou des champs ...
Cordialement,
Bonne idée, elle sera appliquée dans la prochaine version
Quelle est la bonne idée ? : le tri des composant ou lestockage et l'accès à la gestion de constantes de présentation pour certains composants des formulaires ou rapports utilisés de manière répétitive lors de la construction d'une application sous NSBASE ?
J'ai parfaitement notion que cette demande conduit à reprendre beaucoup de lignes de code relatives à l'instanciation des composants ets des assistants... Toutefois cela serait une fonctionnalité trés utile en terme de gain de temps et d'homogénéîté de l'interface d'une application ... aussi utile que la création du choix des champs.
Faites une réponse. Merci,
Last edit: BARRAL Philippe 2020-03-05
le tri des listes, oui l'autre demande qui n'est par fermée, demande beacoup de code...
Procurer un éditeur html au composant MemoHtml.
Cela ne me dérange pas de coder du html ... mais cela serait encore plus simple et rapide avec un éditeur à la manière de TinyMce ou de CKeditor ou d'autres.
Ce n'est pas une demande prioritaire à mon sens.
Cordialement,
il y a un mini editeur HTML en mode "runtime"....
J'ai rajouté l'accès à cet editeur en mode édition dans la prochaine version
Concernant l'onglet "fonctions" à droite dans le mode "code" juste après celui d'"API", les fonctions sont listées 'as is' et la lisibilité n'est pas optimale me concernant. L'affichage, classe pourrait-elles être regroupées sous un titre et les fonctions listées dessous.
je veux dire quelque chose comme cela:
plutôt que :
fonction_nom:fait_ceci()
fonction_nom:fait_cela()
Last edit: Petitpainauchocolat 2020-03-13
Vous avez beaucoup de classes différentes dans un même module?
Last edit: neuts-jl 2020-03-18
C'est implémenté dans la prochaine version
Non c'est surtout une question de lisiblité de noms de fonctions. Ou alors il faudrait que je donne des noms plus courts à mes Formulaires et du coup j'y perds en visiblité d'un autre côté.
Je me demandais aussi, s'il est possible de créer un nettoyeur de code(mise en forme).