›

Comment faire un schéma?

wiskywisky Membre
07:40 modifié dans Objective-C, Swift, C, C++ #1
Salut à  tous,
Je suis en train de faire un logiciel de schématisation. J'ai donc différents types d'objet composant un schéma et ils sont reliés par des objets "liant" (connecteur).
Je développe tout ça avec OBJ-C et je me demande comment faire pour avoir une surface de schéma paramétrable (+ scrool quand il faut) et comment créer mes objets de base ?
La zone de dessin doit avoir un fond de couleur et des règles autours, et les objet doivent être déplassable, etc...

Quel objet de base utiliser?
Accessoirement comment regrouper les objects type dans un fichier.
Merci d'avance ;)

Réponses

  • Eddy58Eddy58 Membre
    07:40 modifié #2
    NSScrollView pour ta surface de dessin, NSRulerView pour les règles. :)
    Pour tes objets de base, soit tu les crées dans un logiciel externe, soit tu fais ton propre éditeur d'objets.
    Pour tes bibliothèques d'objets, NSFileWrapper me semble adapté.
  • tabliertablier Membre
    07:40 modifié #3
    Je n'ai pas la réponse, mais j'ai utilisé en professionel deux produits sur lesquels tu pourrais jeter un ½il.
    Un produit libre (sources fournis):  Electric, site http://www.staticfreesoft.com/
    Un produit payant (voir la version d'évaluation): DessignWorks, site http://www.capilano.com/

    D'autant que j'ai pu m'en rendre compte, DesignWorks est bati sur une base de donnée relationnelle. Un dessin à  l'écran est une vue particulière d'un document de la BDR, de même que l'impression d'un schémas ou la liste des composants. Bon, je ne vais pas refaire la théorie des bases de donnée!
    Ce que j'ai trouvé de bien dans DesignWorks, c'est sa méthode c'accès au bibliothèques d'éléments et la facilité de dessiner un schemas.
  • baleinebaleine Membre
    07:40 modifié #4
    J'ai développé une classe NSView qui répondra peut-être à  ta question. A défault, elle peut servir de base à  un développement.

    http://edouard.fischer.free.fr/EFLaceView.dmg.zip

  • laurrislaurris Membre
    septembre 2006 modifié #5
    Salut Edouard. Merci pour ton code qui est vraiment très instructif sur la façon de créer une NSview "bindable". Avec du coredata en plus ... la totale.

    En ce moment j'essaie de faire un peu la même chose. Je me pose une question sur un point assez précis: dans ta classe comme dans celle de l'example Apple GraphicsBindings, les sous-éléments de la vue (*) sont en fait KVO compliants avec un objet intermédiaire (container... qque chose), mais n'appartiennent pas directement à  la NSView de base. Ca implique un petit raffinement dans l'observation des objets.

    Est-ce qu'il y a une raison importante à  ça (conceptuelle) ou c'est juste pour la beauté du geste ? Qu'est-ce qui empècherait d'avoir un NSMutableArray qui appartient directement à  la vue ?

    Si tu passes dans le coin, j'aimerais bien avoir ton avis parce que j'ai peur de me compliquer la vie inutilement si je copie Â à  la lettre cette manière.

    (*) je précise: sous-éléments= les éléments représentés par un objet "one-to-many" qui est un NSMutableArray.
  • baleinebaleine Membre
    07:40 modifié #6
    Je pense que la raison à  cela, c'est que les mécanismes de KVO standard sont adaptés lorsque le binding porte sur un objet simple, mais ils sont insuffisants lorsque le binding porte sur une collection : en effet, l'observation d'une collection n'emporte pas l'observation de chaque objet de la collection. Il faut donc un objet collection intermédiaire, observer ses modifications, en déduire les objets qui ont été ajoutés ou enlever et mettre en place la KVO de ces objets manuellement.

    dans 1157318906:

    Salut Edouard. Merci pour ton code qui est vraiment très instructif sur la façon de créer une NSview "bindable". Avec du coredata en plus ? la totale.

    En ce moment j'essaie de faire un peu la même chose. Je me pose une question sur un point assez précis: dans ta classe comme dans celle de l'example Apple GraphicsBindings, les sous-éléments de la vue (*) sont en fait KVO compliants avec un objet intermédiaire (container? qque chose), mais n'appartiennent pas directement à  la NSView de base. Ca implique un petit raffinement dans l'observation des objets.

    Est-ce qu'il y a une raison importante à  ça (conceptuelle) ou c'est juste pour la beauté du geste ? Qu'est-ce qui empècherait d'avoir un NSMutableArray qui appartient directement à  la vue ?

    Si tu passes dans le coin, j'aimerais bien avoir ton avis parce que j'ai peur de me compliquer la vie inutilement si je copie Â à  la lettre cette manière.

    (*) je précise: sous-éléments= les éléments représentés par un objet "one-to-many" qui est un NSMutableArray.

  • laurrislaurris Membre
    07:40 modifié #7
    Merci, je vais méditer tout ça.
    Selon ce que tu dis, si j'ai juste une collection de sous-vues et que je veux juste exposer les bindings qui correspondent 1/ à  la collection et 2/ à  la sélection (cad arrangedObjects et selectionIndex), je n'ai pas besoin de passer par cet objet intermédiaire.
Connectez-vous ou Inscrivez-vous pour répondre.