sto predisponendo un atto di aggiornamento per l’inserimento in mappa di un nuovo fabbricato, andando a sopprimere e a fondere le attuali due particelle censite al Catasto Terreni (n. 1475 e 1483), ottenendo un’unica particella all’Urbano (AAA).
Ho predisposto il libretto delle misure e tutto è andato liscio fino alla “Predisposizione dell’atto di aggiornamento per la presentazione in ufficio”.
Arrivato alla funzione “Informazioni Geometriche” per la creazione del modello e cliccando su “inserisci estratto” non succede nulla (non si apre l’estratto cartografico, non compaiono messaggi di errore,…). Come si può vedere dagli screenshot qui sotto l’estratto di mappa viene riconosciuto con n. di prot. e data.
Inoltre, se vado in “Gestione estratti di mappa”, l’EdM risulta correttamente associato al libretto, riesco anche a visualizzare graficamente la mappa e se clicco su “Riscontro grafico Modello-Proposta”, attivando le spunte su “Opzioni di visualizzazione”, l’estratto e la proposta mi risultano correttamente sovrapposte.
In merito al modello censuario, è corretto quello da voi indicato. Nei vari tentativi fatti, per capire la causa del problema, avevo provato a modificare il modello censuario e quello postato era l’ultimo tentativo fatto.
Mentre “AAA+0_P” compare perché ho spuntato tutte le opzioni di visualizzazione dal menù a tendina “Gestioni estratti di mappa”, “Risconto grafico modello-proposta”; in particolare, compare attivando “identificativo fabbricati annessi”.
Il modello censuario e queste opzioni di visualizzazioni, purtroppo, non sono le cause del blocco.
Alla fine non ho capito il motivo del problema ma ho risolto così: ho riscaricato di nuovo l’estratto di mappa, ho installato Pregeo in un altro pc, in questo Pregeo ho importato il libretto precedentemente redatto e poi sono ripartito con la proposta di aggiornamento.
In questo modo non ho più incontrato dei blocchi ed il Tipo Mappale è andato a buon fine.
Non è stato un errore di dati o procedura, perché il contenuto è lo stesso del mio primo tentativo, forse qualche conflitto software o processo corrotto.
Il sistema operativo è Windows 11 e Java versione 8 aggiornamento 491.
Ho avuto nuovamente lo stesso problema e l’ho risolto nel modo seguente.
Il file “PREGEO.INI” risultava presente sia nella cartella %localappdata%\VirtualStore\Windows\ (raggiungibile premendo la combinazione di tasti “Windows + R” sulla tastiera per aprire la finestra “Esegui”, digitando poi %localappdata%\VirtualStore) e sia in C:\Windows.
I due file non erano identici, sia come data di ultima modifica e sia come contenuto, ho eliminato quello collocato nel VirtualStore, che aveva i dati più obsoleti.
Queste operazioni vanno eseguite con Pregeo chiuso.
Può essere che, dopo questa procedura, sia necessario riassociare l’estratto di mappa.
I diversi sistemi Windows aggiornati “alzano” i livelli di sicurezza.
Senza “privilegi” di amministratore e “quant’altro” il S.O. blocca i tentativi di modifica del file.
Il VirtualStore di Windows è una cartella protetta usata dal S.O. per reindirizzare le modifiche ai file di sistema (come pregeo.ini) quando un programma non amministratore tenta di scriverci dentro.
Ci sono “richieste” su forum per “disabilitare” VirtualStore.
Una richiesta particolare conferma l’altra “bestia nera”: controllo account utente.
Anche con i “privilegi” di amministratore alcune “impostazioni” account utente “bloccano alcune funzioni”.
Tanti anni fa complicato “avviare” da PC con Windows (s)Vista un software per APE “caricandolo” da ambiente virtuale: oltre i privilegi di amministratore occorreva “scavalcare” controllo account utente.
La domanda: è proprio “necessario” disattivare Virtual Store?
GPS Global Postural System Se appare il messaggio informativo visualizzato nell’esempio seguente, significa che la cartella dati del GPS, che dovrebbe esistere solo all’interno della cartella ProgramData, esiste anche nella cartella VirtualStore.
La cartella VirtualStore è stata introdotta da Microsoft per i sistemi operativi Windows Vista e successivi e viene utilizzata per virtualizzare la scrittura dei files che l’applicazione tenta di scrivere in cartelle di cui non possiede i permessi di creazione o scrittura.
Quindi non è PreGeo ma il “software esterno di supporto” (GPS - GNSS)
Simili problemi tanti anni fa quando sono “comparsi” i primi file .ini
Non uso PreGeo ma in allora c’era sempre un software che usava un file x.ini)
Il file pregeo.ini contiene percorsi logici (indirizzamenti) che indicano al software dove risiedono i file di lavoro (eseguibili, database temporanei e dati).
Esperienze “interessanti” perché prima “smanettavo” i file .bat e “curiosavo” nei file .pif e .bas
I file .bas erano quelli scritti nel linguaggio Qbasic e nel S.O. D.O.S. “giravano” videogiochi “molto compatti”: sfruttavano meglio la poca memoria disponibile in allora
Per molto tempo l’Agenzia delle Entrate riportava informazioni incomplete per Do.C.Fa. Ora riporta informazioni precise (dipende da “cosa” è installato sul proprio PC e “dove”)
Il file può essere “allocato” in diversa cartella – La “versione” di Java potrà essere “diversa”
Letto solo poco fa la “novità”: file di log SDIPDF.LOG
Nel “passato” non c’era il “richiamo” al file SDIPDF.LOG Come al solito “informazione incompleta”
In realtà il file che “comanda” è SDIPDF.ini che “cerca” il file SDIPDF.LOG
Come facilmente intuibile da PDF …
… è un componente dedicato alla generazione, elaborazione o gestione di documenti PDF
Al momento “una volta per tutte” mi faccio scrivere
da ChatGPT “analisi” file librerie DLL
Segue un estratto “storico” …
Le DLL:
CBLRTSS.DLL
CBLINTS.DLL
COB32API.DLL
DSGRUN.DLL
sono fortemente indicative di un ambiente derivato da Micro Focus COBOL o strumenti COBOL per Windows.
Se questa interpretazione è corretta, una parte del codice DOCFA potrebbe avere radici addirittura negli anni '90, poi migrata a Windows 32 bit.
Altro estratto …
La DLL che più attira la mia attenzione è:
GEARPD.DLL 1.544.192 byte 27/06/2002
È la DLL più grande dell’intero gruppo.
Per confronto:
SDIPDF.dll 131 KB
PdfUtil.dll 258 KB
GEARPD.dll 1.544 KB
Questo fa pensare che il vero “motore pesante” non sia SDIPDF ma GEARPD.
SDIPDF potrebbe essere soltanto il layer SoGei che richiama una libreria PDF commerciale o di terze parti.
Altro estratto …
La DLL che esaminerei per prima, se l’obiettivo è capire davvero come vengono generati i PDF, non sarebbe SDIPDF.dll ma GEARPD.DLL. Le dimensioni e il nome la rendono il candidato più plausibile per essere il vero motore PDF sottostante, mentre SDIPDF.dll potrebbe essere soltanto l’interfaccia sviluppata da SoGei che compare nei log come PDFWriter_xxx.
