Jerzy Dudra

Zrezygnowaliśmy z usuwania zdjęć z poziomu galerii zdjęć obiektu bo zdjęcie może być używane gdzieś indziej (np. w innym towarze). Tworzy to pewne ryzyko, że można "niechcący" usunąć sobie zdjęcie powiązane z innymi towarami. Obecnie jeżeli chcemy usunąć wszystkie zdjęcia towaru "na zawsze" należy: Pobrać galerię zdjęć tego towaru (IAsortyment.PobierzGalerieZdjec()) Z galerii towaru pobrać zdjęcia IGaleriaZdjecObiektu.PobierzZdjecia(); Pobrać globalną galerią Uchwyt.PodajObiektTypu<IGaleriaZdjec>() dla każdego zdjęcia do usunięcia wykonać: IGaleriaZdjec.UsunZdjecie(..) A pisząc po ludzku np. jakoś tak: IGaleriaZdjec galeriaZdjec = uchwyt.PodajObiektTypu<IGaleriaZdjec>(); IAsortyment towar = PodajTowarZeZdjeciamiDoWywalenia(); var galeriaZdjecTowaru = towar.PobierzGalerieZdjec(); foreach (var zdjecieDoUsuniecia in galeriaZdjecTowaru.PobierzZdjecia()) { galeriaZdjec.UsunZdjecie(zdjecieDoUsuniecia); }

Opis z "Inner Exception" może wskazywać na to, że problematyczny plik DLL (tutaj ThemeControls.dll) ma ustawiony atrybut "Zablokowany". Proszę sprawdzić, czy ThemeControls.dll (i prawdopodobnie inne pliki) nie jest zablokowany. Widać do we właściwościach pliku na pierwszej zakładce, poniżej klawisza Zaawansowane. Można to znaleźć w tym miejscu: Windows blokuje czasem pliki skopiowane z lokalizacji sieciowych w ten sposób, ze względów bezpieczeństwa.

Tak przypuszczałem (że chodzi o wersję rozwiązania). Z poziomu rozwiązania własnego nie da się tego wyciągnąć. Zanotowaliśmy sugestię, żeby to udostępnić

Trochę nie rozumiem pytania Chodzi o wersję nexo, czy wersję rozwiązania własnego ? PS. Wersję nexo w rozwiązaniu własnym można odczytać przez DanePolaczenia.WersjaSfery

Problem wynika z tego, że Aplikacja WPF nie ma jawnej referencji do pliku InsERT.Moria.ThemeControls.dll (i jeszcze paru innych). Dlatego podczas kompilacji Pana programu nie ma go w folderze z Pana prograem. Doraźnie można ten problem rozwiązać np. poprzez skopiowanie z SDK brakujących plików do folderu z programem. Lepszym rozwiązaniem będzie jednak posłużenie się szablonem do tworzenia aplikacji wpf, dostarczonym w SDK. Szablony projektów są opisane w dokumentacji w rozdziale 'Szablony projektów dla Visual Studio'

W tej chwili raporty sferyczne nie mają takich parametrów. Zanotowałem sugestię. PS. Gdyby powtórzył Pan występujący u Pana błąd (błąd kompilacji), to czy Mógłby Pan podesłać (na priv) plik z logiem ze stanowiska na którym wystąpił. Chodzi mi o plik logu znajdujący się zwykle w takiej lokalizacji: c:\Users\{użytkownik windows}\AppData\Local\Insert\Logs\NexoLog.txt

Jest błąd po naszej stronie z pewnymi znakami w opisie opcji parametru listowego. Prawdopodobnie użył Pan w opisie opcji tekstu, który zawiera znak " (cudzysłów) lub # (hasz). Zapewne towar ma w nazwie któryś z problematycznych (obecnie) znaków.

Parametr ten nie był projektowany do takiej liczby elementów. Sprawdza się przy liczbie elementów mieszczących się na ekranie (lub trochę więcej).. Czy mógłby Pan napisać ile było elementów na liście? Czy mógłby Pan pokazać fragment kodu generującego parametr powodujący błąd?

Proszę jeszcze pokazać na zrzucie ekranu plik InsERT.Moria.Sfera.dll z katalogu SDK, tak żeby była widoczna data jego utworzenia i rozmiar. Dobrze by było, gdyby mógł Pan pokazać maksymalnie obszerną zawartość katalogu bin SDK'a

To może od końca: nexoSDKSzablony_VS2019 i nexoSDKSzablony_VS2022 to pakiety do Visual Studio z szablonami projektów dla rozwiązań sferycznych. PackageAndInstalledBuilder.exe i QuickInstallerBuild.exe to elementy wykorzystywane w projektach tworzonych z szablonów z pakietów. Jeżeli chodzi o program sferyczny to komunikat taki zwykle wskazuje na rozbieżność między InsERT.Moria.ModelDanych.dll i bazą danych. Upewniłbym się czy na pewno Pana rozwiązanie było kompilowane z SDK zgodnym z bazą danych. Dla wersji 41.0.1 właściwy SDK to NexoSDK_41.0.1.5571.exe. Pisał Pan, że zaktualizowano bazę do wersji 41.0.1, Zakładam więc, że NEXO w wersji 41.0.1 działa na tym stanowisku. Folder, o którym Pan pisze: C:\Users\admin\AppData\Local\InsERT\Deployments\Nexo\Exxxxxxxx2266f8c2095e943b5a608c2\Binaries\ to folder podmiotu, z którym działa Subiekt NEXO w wersji 41.0.1. Jeżeli tak, to proszę sprawdzić czy plik InsERT.Moria.ModelDanych.dll jest taki sam w folderze C:\Users\admin\AppData\Local\InsERT\Deployments\Nexo\Exxxxxxxx2266f8c2095e943b5a608c2 w SDK (w lokalizacji \nexoSDK_41.0.1.5571\Bin w folderze do którego buduje Pan swoje rozwiązanie.

Zwykle taki błąd ('Podana baza danych nie jest .. ') wynika z rozbieżności wersji bazy danych i 'binariów'. Może to być sytuacja, gdy baza jest zaktualizowana do wersji 41.0.1, a 'binaria' których używa rozwiązanie sferyczne są z wersji wcześniejszej. Czy rozwiązanie własne działa na stanowisku, na którym pracuje Subiekt NEXO, jeżeli tak to czy Subiekt się uruchamia? Jak dokładnie wygląda ta referencja?

W najbliższym czasie, nie planujemy dynamicznego generowania kolumn na podstawie wyniku zapytania.

Na 99% z wersją 4.7.2 powinno działać (biblioteki NEXO mają ustawienie 4.6.1) Brak numerów linii w StartTrace w wyjątku wynika zwykle z problemu z plikami PDB w aplikacji, która "rzuca" wyjątkiem. Być może nie wynika on z ustawienia 'Target framework '.

NEXO obecnie używa nowszej wersji Newtonsoft.Josn'a app.config Subiekta dla Newtonsoft.Json ma obecnie takie przekierowanie: <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="Newtonsoft.Json" culture="neutral" publicKeyToken="30ad4fe6b2a6aeed" /> <bindingRedirect oldVersion="0.0.0.0-13.0.0.0" newVersion="13.0.0.0" /> </dependentAssembly> </assemblyBinding>

Czy mógłby Pan przysłać dane diagnostyczne NEXO z tych dwóch stanowisk?