[Ipad]Excel & VBA

[Neo_13]

Salut,

Juste pour rire, ya un mec qui voudrait porter excel avec son vba sur ipad ? Des fois qu'un illuminé en ait déjà parlé sur iphone ???

Ou Windows sur un cortex A9 comme ça, avec un vrai os et un vrai tableur, je pourrais enfin faire de la base de données sur tablet pc pour mon client.

:suicide: (c'est une vrai question issue de réunion) (enfin la partie "notre application sur ipad", le reste, ce sont les détails techniques hors de portée du client)

[ylyad]

Le principal souci, ça va être le VBA... Tu veux pas porter ton code vers Obj-C?

[Yasko]

En dehors de la faisabilité technique d'une telle chose, je pense que ca n'est pas trop dans la philosophie des appareils nomades (du fait de leur autonomie), en déportant un maximum de taf coté serveur (cloud computing & co).

[Neo_13]

Bon tous les deux, zetes viray. Le client, il a pas dit "je veux un truc qui fasse..." mais "je veux un EXCEL qui fasse.... Excel only, je veux que dut excel avec du excel et du excel RIEN d'autre"

Ce que fait mon appli serait méga ultra giga r0xx0r en python/postgresql. Du coup en mode déconnecté, je pourrais le faire marcher partout via sqlite (qui existe pour nokia, iphone, DS, ...) et une interface qui ressemble à quelque chose de sobre...

[olih]

Qemu ?.

Ou alors un truc du style vnc (encore faut il avoir un accès réseau).

[ylyad]

Ce que fait mon appli serait méga ultra giga r0xx0r en python/postgresql. Du coup en mode déconnecté, je pourrais le faire marcher partout via sqlite (qui existe pour nokia, iphone, DS, ...) et une interface qui ressemble à quelque chose de sobre...

[mode fayot]J'avais compris, c'est pour ça que je l'avais pas proposé, pas comme Yasko[/mode fayot]

Bon, ceci dit, il y a une réponse courte: "non, monsieur". Par contre, c'est une super opportunité, sur le mode: "Microsoft ne portera pas Excel sur l'iPhone, jamais, et iWork n'a pas d'équivalent au VBA. En revanche, Monsieur, je peux vous proposer de migrer votre application vers une technologie cross-platform qui lui permettre d'être utilisable de manière nomadesans rien changer à vos habitudes et avec quasiment la même interface utilisateur"

[Neo_13]

Ah ben j'ai déjà répondu "non, on peut pas, et tant qu'on ne sera pas passer sur une vraie base de données, c'est à dire ni excel ni acces, ça restera vrai. Excel, ça pourrait peut etre passé, mais pas les macros, donc ça continuera de calculer, mais ça ne fera aucune des activités de base de données, à commencer par le formulaire de saisie"...

Mais je me renseignais des fois qu'un illuminé ait fait un truc pour me contredire.

EDIT : le client a l'illusion qu'il pourra maintenir mes milliers de lignes de VBA parce qu'il sait enregistrer une macro et la tweaker un pouillième dans excel. Et que du coup la solution excel est plus perenne qu'une base sql.

[ylyad]

T'as bien des SGBD sur iPhone (iSort, Bento), mais faut quand même être malade pour utiliser l'iPhone comme serveur de DB... sans parler du portage

Par-rapport à ton EDIT: prends 2 minutes et montre-lui un programme Python, il verra qu'il peut le tweaker aussi

[Septa]

T'as bien des SGBD sur iPhone (iSort, Bento), mais faut quand même être malade pour utiliser l'iPhone comme serveur de DB... sans parler du portage

J'ai peut être mal compris, mais bon dans le monde windows mobile on utilise sqlce avec des bases sur le pda sans trop de problème de perf... Et ça fait un bail que ça se fait.

Donc bon c'est pas forcément con comme idée.

[ylyad]

T'entends quoi par "pas trop de problèmes de perf"? Si je me base sur les messages précédents du gars Neo, on parle de tables à 100.000+ lignes, avec des macros complexes de calcul sur les données. Bref, j'imagine de la bonne requête SQL bien lourde avec jointures, chapps calculés, etc. et sur un volume plus large que ses contacts ou sa cave à vins. Bref, le truc qui fait vendre du PC bien gros. Donc si ça tourne sur iPhone (je veux bien, j'ai pas de souci, je demande qu'à être convaincu), c'est intéressant

[Neo_13]

En soit les calculs sont faciles.

Je vais faire général et simple pour pas péter mes accords de confidentialité

L'unité, c'est un tableau de 500lignes, 40colonnes en gros, ya un tableau :
- int (variable)
- booléen (variable)
- txt< 255char (variable)
- txt >>255char (fixe) x2
- float (fixe) x5
- int (fixe) x3

Je crois que j'ai fait le tour... Les variables, yen a un par études (100 études, en accroissement), les fixes, sont fixes. On rajoute un peu de trucs à une 40aine d'enregistrements pour les trucs récurrents (pour faire int->humainement compréhensible).

Et des jointures partout, parce qu'on peut prendre le tableau dans tous les sens et à plusieurs en vis à vis. A la case, le groupe de case (non consécutif), la ligne, la colonne, la fraction de colonne, ...

Saisie sur tablet'PC donc formulaire intuitifs requis. Affichage décideurs compliant avec pleins de courbes, d'histo etc... sur pc.

[Septa]

T'entends quoi par "pas trop de problèmes de perf"? Si je me base sur les messages précédents du gars Neo, on parle de tables à 100.000+ lignes, avec des macros complexes de calcul sur les données. Bref, j'imagine de la bonne requête SQL bien lourde avec jointures, chapps calculés, etc. et sur un volume plus large que ses contacts ou sa cave à vins. Bref, le truc qui fait vendre du PC bien gros. Donc si ça tourne sur iPhone (je veux bien, j'ai pas de souci, je demande qu'à être convaincu), c'est intéressant

J'avais pas vu le volume.

Ouais pour les tables avec plus des centaines de millier d'enregistrement et des jointures partout ça suit plus vraiment et on triche. Genre avec des fichiers plats et des expressions régulières pour quand c'est que de la consultation de données.

[Neo_13]

Genre avec des fichiers plats et des expressions régulières pour quand c'est que de la consultation de données.

C'est au moins aussi classe que de se servir d'excel et de la localisation x.y comme critère de jointure, ça