Lista postări despre Office interop pe Silverlight:
Acesta este primul post dintr-o serie de trei sau patru posturi în care o sa discutam despre Silverlight și interop (Office interop).
Dupa cum știm Silverlight suporta integrarea cu Office prin intermediul la interop, dar înainte sa ne aruncam cu capul în fata în API si sa vedem ce putem face o sa prezint ce nu putem face din Silverlight.
Nu avem acces la API-ul de Office in totalitate. Chiar daca in teorie folosim COM-urile de Office nu o sa putem apela orice metoda. De exemplu din cauza modului in care o aplicație Silverlight ruleaza pe o masina, nu o sa putem face pe client new la un nou document.
Dar acest lucru este cauzat direct de Silverlight, care nu ne permite sa generam fisiere pe client (in modul in care Office-ul are nevoie).
O solutie la aceasta problema este crearea fisierului pe server, iar apoi sa il copiem pe client. Putem sa avem templaturi care sa le copiem pe client si prin duplicarea lor sa replicam comanda de new.
Din cauza ca folosim obiecte de tip dynamic, putem foarte usor sa gresim apelul unui metode, iar apoi partea de debug pentru a identifica problema o sa fie criminala. Recomand crearea unui wrapper peste API-ul de Office.
Cand o sa incercam sa apelam o metoda o sa observam ca trebuie sa trasmitem ca si parametru valoarea unui enum de care nici nu am auzit pana atunci. Pentru a putea sa il folosim este nevoie sa apelam la msdn si sa trasmitem valorea efectinva a acestuia ca si un intreg.
O alta problema pe care aduce Silverlight-ul si pe care nu o putem rezolva este imposibilitatea de a transmite parametri prin nume:valoare.
De exemplu API-ul de Office este plin de metode cu parametrii optionali, dar din pacate noi nu o sa putem scrie:
Acesta este primul post dintr-o serie de trei sau patru posturi în care o sa discutam despre Silverlight și interop (Office interop).
Dupa cum știm Silverlight suporta integrarea cu Office prin intermediul la interop, dar înainte sa ne aruncam cu capul în fata în API si sa vedem ce putem face o sa prezint ce nu putem face din Silverlight.
Nu avem acces la API-ul de Office in totalitate. Chiar daca in teorie folosim COM-urile de Office nu o sa putem apela orice metoda. De exemplu din cauza modului in care o aplicație Silverlight ruleaza pe o masina, nu o sa putem face pe client new la un nou document.
Dar acest lucru este cauzat direct de Silverlight, care nu ne permite sa generam fisiere pe client (in modul in care Office-ul are nevoie).
O solutie la aceasta problema este crearea fisierului pe server, iar apoi sa il copiem pe client. Putem sa avem templaturi care sa le copiem pe client si prin duplicarea lor sa replicam comanda de new.
Din cauza ca folosim obiecte de tip dynamic, putem foarte usor sa gresim apelul unui metode, iar apoi partea de debug pentru a identifica problema o sa fie criminala. Recomand crearea unui wrapper peste API-ul de Office.
Cand o sa incercam sa apelam o metoda o sa observam ca trebuie sa trasmitem ca si parametru valoarea unui enum de care nici nu am auzit pana atunci. Pentru a putea sa il folosim este nevoie sa apelam la msdn si sa trasmitem valorea efectinva a acestuia ca si un intreg.
O alta problema pe care aduce Silverlight-ul si pe care nu o putem rezolva este imposibilitatea de a transmite parametri prin nume:valoare.
De exemplu API-ul de Office este plin de metode cu parametrii optionali, dar din pacate noi nu o sa putem scrie:
document.Find("text",Page:10,Title:false)
document.Find("text",Type.Missing,Type.Missing,Type.Missing,
Type.Missing, 10,Type.Missing,Type.Missing,Type.Missing,Type.Missing,Type.Missing,false,Type.Missing, Type.Missing)
Comments
Post a Comment