Confermo il programma è esageratamente lento.

Nel momento in cui si visualizza l'anteprima del sito, WebSite X5 rigenera i file che sono stati modificati; In alcuni casi le modifiche eseguite implicano una rigenerazione più estesa, la cui durata dipende dalla dimensione del sito.

Vi consiglio di verificare le preferenze del programma per modificare il numero di processi paralleli a seconda della potenza e delle capacità del vostro processore.

Già settati al massimo il numero di processi paralleli. Dopo aver riavviato il pc la situazione è leggermente migliorata, ma spesso si pianta e rimane bloccato per più di un minuto per poi riprendere normalmente a lavorare.

Inoltre ho importato un sito fatto con la versione precedente e tutte (o quasi) le immagini contenute in una casella di testo sono da reinserire manualmente perchè evo 9 non le legge. 

Confermo le immagini nelle caselle di testo nella vers. 8 si vedono in anteprima ma non nella casella stessa vers. 9

Ciao,

confermo la lentezza del programma ed inoltre ho notato un eccessivo consumo delle risorse del mio portatile: occupa sempre circa 300 MB di memoria e quando deve modificare il progetto circa il 95% del processore. E' normale secondo voi?

Grazie

Sono almeno due mesi che lo sto dicendo senza avere riscontri ed alla fine mi sono stancato.

Ho provato a ridurre i processi, ma il problema permane, anche se adesso i rallentamenti o i blocchi sono meno continui.

anche a me fà la stessa cosa ed essndo il sito di circa 600 pagine ci mette ore a rigenerare il tutto , penso proprio di tornare alla 8 e comunque aspetto siegazioni da incomedia.

altra domanda da dove cambio i processi?

Il numero di processi concorrenti può essere cambiato dalle impostazioni nel programma. Le impostazioni si possono trovare nella prima schermata che viene visualizzata all'apertura nel menu a sinistra.

Io ho ridotto i processi a tre, ma non c'è stato alcun miglioramento. Ogni volta che si aggiorna il progetto il processore viene utilizzato quasi al 100% surriscaldando parecchio il portatile. Segnalo che il processore non è di ultima generazione, ma ha una discreta potenza.

L'utilizzo di processi concorrenti da reale beneficio solo in caso di processori multicore.

Se il suo processore non è di questo tipo le consiglio di impostare questo paramentro al minimo. In caso contrario le migliori prestazioni si ottengono impostando questo paramentro ad un numero uguale o multiplo del numero di core a disposizione.

Il portatile è dotato di un processore Mobile DualCore Intel Core 2 Duo T9400, 2533 MHz, ma se non sbaglio il multicore è riferito a una CPU composta da tre o più core.

Quindi, nel mio caso dovrei impostare i processi al minimo, ossia a 2. E' corretto?

Il suo processore è multicore, ne ha 2.

Le consiglio di impostare 2 o 4 processi simultanei dato che è un processore mobile.

Giusto, ma incompleto.

Durante le varie fasi della lavorazione di un progetto, anche gli accessi al disco sono gestiti con processi concorrenti, ovvero da due in su e pertanto essendo l'accodamento degli i/o su disco seriale (ide o sata è la stessa cosa) si ha un peggioramento di performance rispetto al caso in cui l'accesso sia esclusivo.

In fase di beta test avevo più volte ripetuto questa cosa, ma evidentemente non c'e' peggior sordo di chi no vuol sentire.

Questo collo di bottiglia può essere superato SOLO in due modi:

1) consentire l'accesso al disco in modalità esclusiva, ovvero un thread (sbagliato parlare di processi) per volta, ma questo non è possibile in quanto mi sembra che abbiate impostato il minimo a due

2) utilizzare tecnologia scsi o sas .... ma allora non siamo più su notebook o pc consumer

Se occorre una disquisizione più tecnica e maggiori dettagli, rimango a disposizione.

... uhm ... neanche troppo giusto, comunque, poichè c'e' da considerare che anche i processori monocore non eccessivamente paleolitici sono dotati di pipeline multipla (il 486 ne aveva una sola ed il pentium ne aveva già 2) per cui consentono un minimo di parallelismo.

Come avevo già detto durante il periodo di Beta testing, come icn, i processi non si limitanto ad eseguire operazioni di I/O. Dato che ogni processo esegue una quantità notevole di operazioni fisicamente parallelizzabili e una piccola parte di operazioni seriali il beneficio c'è e si può anche misurare. Ovviamente abbiamo eseguito dei test sul rendimento della generazione delle pagine a seconda della quantità di processi e dell'hardware a disposizione.

La differenza tra i processori a singolo core e quelli multicore è che le operazioni in un processore multicore sono parallelizzate in modo reale, cioè vengono eseguite più operazioni contemporaneamente, in quelli monocore la parallelizzazione può essere solo virtuale, cioè le operazioni vengono eseguite in serie anche se il processore può spezzarle in frammenti ed eseguirle incastrandole tra di loro.

Lento lento lento. Dovevate dirlo che insieme alla versione 9 occorreva comprare un pc nuovo. Uso website da anni. Appena uscita la 9 l'ho comprata ad occhi chiusi. Non mi aspettavo un simile tradimento. Io sviluppo (per mie esigenze personali) esclusivamente sul portatile che è un "misero" sony vaio con pentium M 760 2GHz. 

Forse questa versione va bene per chi sviluppa un sito da zero. Forse per chi ha appena cambiato il pc. Ma chi come la vostra maggior parte di clienti aveva siti con più di cento pagine non può stare a guardare il pc mentre il programma aggiorna tutto il sito. Come dice il comico Crozza non siamo mica qui a pettinar le bambole.

Oramai ho il terrore di modificare una virgola nel layout. Ieri sera, al termine della giornata lavorativa, clicco su salva e il programma vuole aggiornare tutto. NOOOO! Aspetto un po'. Devo andare via. Butto giù tutto. Chiudo e domani si vedrà. Questa mattina riaccendo, riparto e il programma mi dice che non era stato chiuso correttamente e deve riaggiornare e il sito. OK. Ci mette ben 46 minuti. Per poco più di cento pagine.

Primo suggerimento a Incomedia: lasciare all'utente la scelta di aggiornare tutto. Ritornare al sistema della versione 8 dove era possibile visualizzare l'anteprima solo per la pagina in lavorazione.

Nel frattempo abbandono la versione 9 per ritornare deluso, molto deluso, alla versione 8.

Sicuramente, ma il problema è che lo fanno (mentre invece gli i/o devono essere effettuati in maniera esclusiva) mentre fanno anche tante altre cose che possono essere fatte efficientemente in parallelo.

Ho visto e monitorato direttamente con i miei occhi la creazione di 3 o 4 files contemoraneamente e ti mandai anche degli screenshot

A patto di non avere file di dimensioni medio-grandi e di avere un disco particolarmente deframmentato. Uno dei problemi è che non ascoltate gli interlocutori dando per scontato che siano ignoranti in materia, mentre non è sempre così.

Ho in catalogo anche dei corsi di sistemi per l'elaborazione dell'informazione oltre a corsi di programmazione in c/c++ .... so quali sono le varie differenze.

C.V.D.

Ti ringrazio molto per questo suggerimento che prenderemo sicuramente in considerazione. Abbiamo già dato la possibilità di non creare il sito in parallelo alla lavorazione, a questo punto valuteremo la possibilità di non creare il sito al salvataggio, operazione che era necessaria per integrità del progetto. Nella versione 8 questo non succedeva ma all'apertura veniva creato il progetto intero, la versione 9 tende a ricreare solo le parti necesarie in ogni caso.

Per spiegare come si presentano i benefici vi faccio un esempio.

Se prendiamo 2 processi che elaborano, ad esempio, un'immagine, questi processi saranno composti da 3 stadi principali: lettura, elaborazione, scrittura. La lettura e la scrittura non sono parallelizzabili tra di loro ma sono parallelizzabili con l'elaborazione.

Se i 2 processi hanno queste tempistiche:

1. 1 lettura, 3 elaborazione, 1 scrittura
2. 2 lettura, 1 elaborazione, 2 scrittura

Nel caso di elaborazione seriale i due processi impiegheranno 10 in caso di parallelo i due processi impiegheranno 7.

Spero di essere stato esauriente. Potete trovare maggiori informazioni in questo articolo: http://en.wikipedia.org/wiki/Parallel_programming (è in inglese ma ha un corrispettivo italiano)

Ascolta, se vuoi aver ragione a tutti i costi, ok e non è necessario perderci altro tempo. Se vogliamo discuterne, possiamo farlo.

Premettendo che stiamo parlando di lettura/scrittura su disco e non su ram, se tu analizzi il caso del tuo esempio e metti le due sequenze sull'asse dei tempi, hai che il primo thread esegue una lettura contemporaneamente al secondo nel primo intervallo temporale, nel secondo hai elaborazione pura e nel terzo ha due scritture contmporanee.

Il secondo intervallo viene correttamente eseguito in multithread. Il primo ed il terzo hanno le stesse caratteristiche ed ora le vediamo in dettaglio.

Il disco è organizzato in piatti (mediamente da due a quattro), tracce (cerchi concentrici) e  settori (area dell'intersezione tra la traccia ed uno spicchio di piatto, A, B, C e D nella figura), per trovare il settore su cui scrivere è necessario spostare il carrello delle testine sulla traccia ed aspettare che il settore corrispondente passi sotto la testina.

http://upload.wikimedia.org/wikipedia/commons/thumb/4/49/Hdd_od_srodka.jpg/300px-Hdd_od_srodka.jpg

http://it.wikipedia.org/wiki/File:Disk-structure.svg

Ogni settore contiene 512 bytes ma siccome il carrello delle testine e un oggetto rigido e le testine sono montate staticamente sui braccetti, conviene eseguire le letture/scritture su gruppi di settori.

Tutte le tracce sono numerate così come i settori ed i piatti, allora prendiamo tutte le tracce zero, ovvero traccia zero del piatto zero lato superiore, traccia zero piatto zero lato inferiore, traccia zero piatto uno lato superiore, traccia zero piatto uno lato inferiore e così via ..... otteniamo il cilindro zero .... andiamo avanti con la traccia 1, la traccia 2 e così via ed otteniamo una suddivisione di tutto il disco in cilindri.

Con questa nuova rappresentazione la singola lettura coinvolge un intero gruppo di testine in un colpo solo e parliamo di qualcosa che si avvicina ad un cluster, ma non è un cluster, ma il concetto è simile, e interessa 1, 2 o 4kb di dati, a seconda della geometria del disco, piuttosto che 512bytes.

Quindi l'operazione di lettura/scrittura prevede il posizionamento del gruppo testine sul cilindro in cui si trovano i dati e poi bisogna aspettare che i piatti, girando, capitino sul settore di riferimento.

Se abbiamo due scritture simultanee o due letture simultanee che non interessano l'intero file ma solo una piccola porzione che dipende da tanti fattori tra cui la dimensione del buffer, il gruppo testine è sempre uno, e quindi le operazioni devono essere eseguite in sequenza e non in parallelo, ma c'e' un problema e cerco di spiegartelo con un'esempio.

Immaginiamo che il file interessato dal primo thread sia costituito da blocchi di dati che indico con lettere minuscole "abcdefg" ed il secondo con lettere maiuscole "ABCDE" (il secondo è più corto, ma è solo un esempio) ed i singoli blocchi di dati non sono vicini ma abbastanza sparpagliati sul disco (frammentazione esterna) come sempre.

Nel caso monothread abbiamo che i blocchi verranno interessati in questa sequenza, più o meno,  "abcdefgABCDE", mentre nel caso multithread "aAbBcCdDeEfg" e fin qui non c'e' nulla di discutere, è così e basta.

Allora dobbiamo considerare che se il disco e deframmentato la sequenza abcdefg è memorizzata con i blocchi uno vicino al successivo e così per la seconda sequenza e quindi la lettura della sequenza abcdefg, da sola, viene fatta di volata perchè i dati sono vicini e la stessa cosa per la seconda sequenza. Mentre non è affatto detto che le sequenze siano vicine ed è rarissimo che lo siano perchè gli algoritmi di gestione dei filesystem lavorano sempre in maniera ordinata.

Il tempo di spostamento del gruppo testine da una traccia all'altra è dell'ordine di 7-12 millisecondi .... se le tracce sono 2 i tempi sono 14-24 millisecondi e così via, quindi è evidente che se io riduco gli spostamenti traccia-traccia ottengo prestazioni migliori.

Se i file sono lontani e devo simultanemente cercare i settori del primo ed i settori del secondo, poi il secondo settore del primo ed secondo el secondo e così via .... ho il risultato che ste benedette testine saranno costrette a fare avanti e dietro continuamente sprecando tempo prezioso.

Esercizio per casa: prendi due file grandi, molto grandi per poter apprezzare le differenze in maniera molto eclatante e li copi da qualche altra parte prima in sequenza e misuri il tempo e poi contemporaneamente e misuri nuovamente il tempo. Confrontare il tempo necessario per eseguire le due operazioni e scrivere le proprie impressioni.

PS. Utilizzando dischi SCSI o SAS viene fatto, dal controller e dall'elettronica del disco (per questo sono molto più costosi), un riordinamento/ottimizzazione degli accessi al disco per migliorare o meglio ridurre al minimo il tempo perso per il traccia-traccia.

Ho scritto di getto e non ho troppa voglia di rileggere tutto il papiro, quindi perdonami gli errori ortografici e/o grammaticali (spero che almeno questi ultimi non ci siano).

PS. L'articolo da te postato parla di accessi alla RAM e non al disco, quindi due casi moooolto diversi. C'e' la meccanica del disco a fare la differenza.

Leggi qui:

http://it.wikipedia.org/wiki/Disco_rigido

E tieni presente che l'NCQ, nella pratica,  pur migliorando notevolmente le prestazioni rispetto agli IDE, è ben lontana dall'equivalente di mamma SCSI.

La lettura e la scrittura vengono eseguite in serie, quindi il problema del disco non sussiste. Le operazioni di elaborazione sono indipendenti da queste problematiche.

Nel caso peggiore la sequenza che usavo prima come esempio diventa:

1. lettura del primo processo, di valore 1
2. prima parte dell'elaborazione del primo processo in parallelo alla lettura del secondo, di valore 2
3. seconda parte dell'elaborazione del primo processo in parallelo a elaborazione secondo processo, di valore 1
4. scrittura primo processo, di valore 1
5. scrittura secondo processo, di valore 2

Il totale è come dicevo prima di 7. E' un dato di fatto.

Spero di essere stato esauriente e che la discussione si possa ritenere chiusa, anche perché striamo divagando

Deve essere per forza così, non è possibile diversamente. Non è possibile selettivamente impostare alcune testine in lettura ed altre, simultaneamente, in scrittura o addirittura fare in modo che i dati di una lavorino su una sequenza di dati ed un'altra testina su una sequenza diversa e sempre simultaneamente. L'elettronica controlla l'intero gruppo come se fosse un'entità unica ed indivisibile.

Quello che tu dici, e qui' ti do perfettamente ragione, è riferibile solo alle elaborazioni su file di piccolissime dimensioni, ovvero prevalentemente html e php (enormemente comprimibili, oltretutto) che si leggono al volo con uno o al massimo 2 o 3 cicli di lettura e non su file di dimensioni enormi e su cui il maggior costo in termini di risorse si sposta dalla cpu al sistema di I/O.

Nel caso che ho monitorato direttamente ed ho documentato, a parte la diagnosi acustica (non è una presa per i fondelli ma persino un test previsto dalle case costruttrici degli hard disk) che la dice lunga sullo stress a cui viene sottoposto il disco, ero in presenza di file multimediali (*) di dimensioni abbastanza grandi per accentuare il problema per il cui spostamento (**) sarebbe stato necessario un enorme costo in termini di I/O ed un bassissimo costo in termini di cpu e quindi quello che dici tu è inapplicabile in quanto la parte elaborativa poteva essere letteralmente e tendenzialmente azzerata rispetto al resto.

"Sarebbe" .... "poteva" ..... allora, diabolicamente , per far ritornare i calcoli a quanto da te illustrato, cosa avete fatto? Avete pensato bene di forzare la compressione dei files (*) multimediali (che nel caso di divx, mp3, mpeg, jpg etc etc ... non png e gif) che sono per definizione "incomprimibili" o per lo meno "scarsamente comprimibili"..... scarsamente al punto tale che tutto il mondo, meno icm, valuta che il costo computazionale della compressione non è rapportabile ai benefici  (ammesso che benefici ci siano in quanto oltre al file incomprimibile, c'e' la generazione del famoso "dizionario" che a volte ingrandisce, addirittura, i file) e quindi evita completamente le compressioni di quel tipo se non con particolari accorgimenti tipo "dizionari specializzati" (winrar o winace, ad esempio) oppure ricorre alla zero-level compression, ovvero memorizzazione senza compressione, con l'algoritmo del winzip è l'unica possibilità.

Che la compressione venga tentata ugualmente è visibile in quanto se si apre lo zippato si legge lo 0,qualcosa per cento di compressione mentre era banalmente eseguibile una discriminazione su cosa comprimere e cosa no .... e ne parlammo anche.

Gli effetti di tutto questo:

1. Ulteriore rallentamento.
2. Surriscaldamento della zona disco del pc.
3. Surriscaldamento della cpu.
4. Aumento del rumore a causa della necessità di maggiore ventilazione

ce ne sarebbero altri, ma non voglio che si pensi che i faccio le pippe mentali.

Nel tuo esempio precedente,

Tra il punto 1 ed il punto 2, se sono riferiti a file diversi, hai lo spostamento delle testine=1 spostamento.

Tra il punto 2 ed il 3 spostamento=0

Tra il punto 3 ed il 4 spostamento=1 (file diversi)

Tra il punto 4 ed il 5 spostamento=1 (file diversi)

totale= 3 spostamenti

Se tu avessi sequenzializzato le operazioni fin dal principio avresti avuto, grossomodo quest'ordine:

1. lettura del primo processo = 1 spostamento
2. eleborazione del primo processo (vabbè... thread, processo è sbagliato): 0
3. scrittura primo processo: spostamanto=0 (file di piccole dimensioni e quindi uno o due cicli di lettura o scrittura con altissima probabilità sequenziale): spost=0 (testine già in posizione)
4. lettura del secondo: spostamento=1
5. elaborazione del secondo: spost=0
6. scrittura secondo processo: spost=0 vedi sopra, stesso motivo

Totale: due invece di tre.

Semplificando ed approssimando all'estremo, se i files sono di dimensioni medie, diciamo 2 megabyte, facendo due calcoli facili e a spanna circa 512 cicli di scritture fisiche, ben diverse da quelle logiche e controllabili con le fopen() e fwrite(), con un risparmio del 30% del tempo, ovvero un tempo che va da 1,2 secondi a 2,4. Non è poco. Per un progetto di 100megabyte si avrebbe un risparmio stimato, solo a causa dell'ordine delle operazioni su disco, di 1 o 2 minuti. In fase di test, chiedeste di fare dei test con progetti grandi e su 3 giga potete immaginare cosa è uscito fuori. Più di un'ora di perdita di tempo e che nella pratica lievita inesorabilmente (non c'e' mica solo website in esecuzione su un pc, più sono i cicli di I/O su risorse e più aumenta la probabilità di perdere tempo con i lock, i semafori ... più aumenta la strada e più aumentano i semafori che potrebbero anche essere rossi). Poi c'e' tutto il resto, ovviamente.

Mirko Nosenzo

Spero di essere stato esauriente e che la discussione si possa ritenere chiusa, anche perché striamo divagando

Così come un mese fa, anche oggi, se pensi che la soluzione sia ignorare l'argomento, sei libero di adottarla, ma personalmente la ritengo una soluzione strategicamente sbagliata.

Un'altra cosa che assolutamente non mi piace di questo answer, così come in parte sul vecchio forum (pace all'anima sua), è l'impossibilità di affrontare argomenti diversi ... utili a quanti non hanno mai visto un pc e magari rischierebbero anche di imparare qualcosa ..... che vengono chiusi con un nulla di fatto. Vorrei solo far notare che per scrivere questo post ed il precedente ho impiegato più di un'ora del mio tempo senza alcuna parcella. Se le stesse cose le avessi detta in aula, sarei stato pagato profumatamente ed avrei acquistato direttamente la versione completa del vostro nuovo programma, un'ora-una copia del programma ..... mentre invece dopo due o tre giorni sto ancora aspettando una risposta sul fatto di poter gestire diversamente l'upgrade che scelleratamente ho fatto senza pensarci dalla 8 alla 9.

Sono molto deluso da tutto questo.

E' per questo che non è possibile fare calcoli sullo spostamento delle testine. Inoltre i file vengono letti in un punto del disco e scritti in un altro.

Qui ti riferisci all'esportazione del progetto, processo puramente sequenziale. In ogni caso la compressione non viene eseguita, viene semplicemente creato un file unico per questioni di semplicità di spostamento dei dati da parte dell'utente.

Non voglio chiudere la discussione per ignorarla ma semplicemente perché stiamo divagando. Si tratta di scelte tecniche che hanno bisogno di essere valutate con attenzione e questa probabilmente non è la sede adatta.

Dipende dal metodo con cui apri il file. E' possibile lavorare direttamente sul file.

Non esiste una sede diversa, ma non importa. sono rassegnato a rimanere nella mia ignoranza.

Ma ci sono tre dati di fatto:

1. non hai eseguito il compito per casa o, se l'hai fatto, non mi hai dato i risultati
2. molti lamentano problemi compatibili con la mia diagnosi 
3. dopo quasi tre giorni, ancora nessuno fornisce unaansweralla miaquestion, quella pubblica o la stessa che ho reso privata come mi avete chiesto all'inizio

Approposito, avete dimenticato di correggete la pagina del manuale ...

ehm ... c'e' qualche problema di formattazione. Il nuovo coso di incomedia ha trovato un coso più grande di lui.

resta il fatto che ora con la versione 9 è diventata un'odissea aggiornare il mio sito mentre prima con la 8 era molto + veloce ed in pochi minuti faceva il tutto non riesco a capire perche'.

Il perchè è semplice. Il problema c'e', c'e' sempre stato fin dalle primissime beta, ma la soluzione non c'e'. Io sto continuando ad usare la 8, poichè il progetto per cui mi serve è grande circa 1 Gb e non mi va di invecchiare nell'attesa dei vari spostamenti, compressioni, vere o finte che siano .... comunque è tempo perso .... ed il tutto anche solo per una stupida virgola.

Avevo chiesto informazioni per entrare nella rete dei rivenditori, cosa di meglio che rivendere un prodotto per cui si riesce a fornire anche l'assistenza tecnica di base, ma un sesto senso mi spinse ad aspettare la nuova release ... ed infatti obbiettivamente, se non viene migliorata la faccenda della velocità, non me la sento di riprendere il discorso.

domenica prenderò il tempo esatto che ci vuole ad aggiornare il mio sito circa 600 pagine e lo pubblicherò qui e su un post apposito chiedendo lumi e una risposta da parte di incomedia sul perchè di questa lentezza visto che in questo post chiacchere tante ma risposte dal loro staff zero.

Io, dal canto mio, ho smesso di chiacchierare su questo post. Tutta fatica inutile. Esattamente come altri due topic che mi interessavano particolarmente in quanto trattavano un caso di upgrade diverso dagli altri ed un altro piccolo problemino di discriminazione .... ma va a finire che ci metto una pietra sopra. Oramai, con il fatto di unofficialwsx5.com e qualche discussione di troppo .... sono diventato un utente scomodo.

Approposito ... e chiudo sul serio.

Nell'esperimento test a cui avevo fatto riferimento .... un progetto grande ... 1 gigabyte di roba ..... beh ..... messo avanti la sera, con il notebook su quattro oggetti agli spigoli per tenerlo sollevato dal tavolo e ... killato il processo la mattina seguente .... non aveva ancora finito e dovevo andare al lavoro .... ed io non inizio prima delle 9.

Vediamo come ti ho detto domenica aggiornerò il sito e cercherò di prendere il tempo.

io uso un desktop ma il processore non è un ultimissimo modello , eè uno dei primi dual core ed ho solo 2 Gb di ram...(mi vien da ridere a dir soli il mio primo pc se non erro ne aveva 256k e la ram costava 200000 lire a Mb).

Saluti Michele

E' tutto lentissimo se si importano vecchi progetti realizzati con la vers. 8 sulla 9... Una volta convertito il progetto (ci ha messo intorno agli 8-10 minuti, e va bene, visto che lo deve fare solo la prima volta che si importa) quando poi vado ad aprire la home page, la sua visualizzazione è lentissima (non parliamo poi di un paio di file flash presenti in home che me li visualizza con una lentezza assurda! Fa prima ad arrivarti un rimborso INPS che non la visualizzazione dell'animazione Flash nell'anteprima!!). Se poi dalla home clicco sugli altri collegamenti del menù ci mette un'eternità per aprire le altre pagine.. Questi problemi erano INESISTENTI con la versione 8!! (utilizzo lo stesso PC che utilizzavo con la 8 fino a qualche giorno fa). Vorrei tanto poter ritornare alla 8 e abbandonare questa nuova versione che fino ad ora mi ha creato mille problemi, compresi quelli relativi alla quasi nulla compatibilità con la maggior parte dei mie siti creati con la versione 8...... E leggo anche che tutti questi problemi erano stati segnalati in fase di beta test... Stavolta mi sa che Incomedia abbia pensato solo a rimpinguare le sue casse e non abbia tenuto conto minimamente delle esigenze di clienti storici che, come me, usano website dalla versione 7.... Ero rimasto sempre soddisfatto dei prodotti Incomedia, tranne in quest'ultimo caso relativo alla versione 9. Una vera grande azienda dovrebbe sempre migliorare i propri prodotti e dovrebbe tenere in grande considerazione la soddisfazione del cliente: mi dispiace per come stanno andando le cose pe Voi, ora potete solo dimostrare di tenerci ai Vs. clienti eliminando tutti i problemi ormai appurati e conclamati di questa nuova versione... E' l'unica cosa giusta e sensata che potete fare Voi di Incomedia invece di perdere tempo in spiegazioni arzigogolate che di certo non interessano a chi ha sborsato i propri soldi e vuole solo lavorare tranquillamente e senza intoppi e stress con il Vs. programma.

Buon lavoro

Sono completamente d'accordo con tutti voi: lentissimo, super lentissimo... ore e ore per un'anteprima o per un salvataggio... sono ritornato alla versione 8 velocissima... pensavo che dipendesse dal mio progetto... spero solo che Incomedia risolva tutti questi problemi di lentezza dato che l'abbiamo già finanziata. Ancora grazie a tutti voi

Oltre alla lentezza ci sono vari bug..

E' sicuramente vero che l'utente medio decide di scrivere in un "coso" di supporto prevalentemente quando vengono riscontrati problemi mentre al contrario non si sognerebbe di farlo solo per dire che "va tutto bene".

Detto questo, però, e a memoria, non ricordo tanto malcontento riferito ad un singolo problema della versione 7 o della 8.

La mia conclusione è che senza volersi arrampicare sugli specchi facendolo passare come uno sport alla moda, forse occorrerebbe fare un passetto indietro e rivedere la politica di gestione di due aspetti importanti:

1) il sistema di gestione delle anteprime

2) il sistema di gestione delle esportazioni

Oramai ho perso la voglia di spiegare il motivo di questo mio consiglio che gratuitamente non ha alcun valore, ma che se fosse seguito dal saldo di una parcella, avrebbe un valore diverso.

In effetti, appena ho tempo ..... per ora sono iper-impegnato con l'altro forum .... potrei cercare di ricostruire i vari aspetti di questa storia documentandoli .... anche se icm dovrebbe già avere tutto.

Approposito ... il coso non piace proprio a nessuno ... gli unofficialwsx5 stanno spuntando dappertutto .... come abbondantemente previsto.

Sono d'accordissimo con Ser Zio.... "Passetto indietro" e contenti tutti! Ci vuole poco, dai...... 

He adquirido la version 9. Mi sitio esta diseñado con la version 8. Esta compuesto por su pagina principal en español y otra carpeta (LANG1) en ingles. Siguien las instrucciones, importe ambas carpetas. Cuando voy al otro paso (cambiar a la v9) Lang1 se carga normalmente. Pero la carpeta con la pagina principal, luego de algunos segundos da este ERROR::

""El índice está fuera del intervalo. Debe ser un valor no negativo e inferior al tamaño de la colección. Nombre de parámetro: índex""

Favor, no entiendo mucho del lenguaje, pero desearia saber si alguien conoce alguna solucion que este a mi alcance. Muchas gracias. Miguel Angelhttp://www.machtres.com

Hola Miguel,

por favor, envíanos tu archivo de proyecto creado con la versión 8 abriendo un post nuevo y nosotros iremos a verificar.

Gracias.

Che versione di Internet Explorer hai sul tuo sistema?

Ciao Giuseppe, son contento che hai capito cosa non andava sul tuo PC.

Penso che possa dipendere da IE o dalla scheda video del tuo PC. Ti posso dire che nella 8 il testo in movimento era fatto con l'utilizzo del tag (deprecato) MARQUEE, mentre ora è fatto con JavaScript pertanto il browser deve eseguire il codice per il movimento del testo.

Mirko, dici a me? Io ho IE 8 in quanto uso Windows XP (con service pack 3)

A me il testo in scorrimento riga unica orizzontale nel rollover sia con evo 8 che evo9 sembra lo stesso e con gli stessi difetti sopratutto visto poi con IE

Riferendomi a quanto ho scritto precedentemente: con la beta dell'aggiornamento ora va tutto OK e le anteprime di una pagina del sito non presentano più problemi di lentezza nella visualizzazione anche con roll over abilitato nella pagina.  

mah

Perchè non lo provi? Chissà che ora si parli di un prodotto acquistabile!?!?!?

Approposito .... con il coso non è possibile scambiare messaggi privati con gli utenti?

GDR, SER ZIO, "va tutto ok" è riferito al problema che io ho riportato qui...parlavo di questo post, sia chiaro ,  meglio evitare fraintendimenti, infatti ho anche rimarcato qual era il problema al quale mi riferivo e che con la beta è risolto: quello dell'anteprima lentissima di una pagina se avevo un roll over di testo abilitato nella stessa!  Il resto è tutto da verificare ancora.....

Ancora è lontana la velocità di avvio che ha contraddistinto le precedenti versione...quindi: ottimizzate, ottimizzate ancora.

Devo dire che ci sono stati molti miglioramenti con l'ultima versione ora il programma è usabile rimane la lentezza nel salvataggio quando al progetto si aggiunge una pagina( nel mio caso + di 20 minuti sito di circa 650 pagine) cosa che con la versione 8 era molto veloce.

saluti

NUOVA VERSIONE LENTISSSSSSIMA -

 WEBSITE DEVE URGENTEMENTE  TROVARE DEI RIMEDI - TUTTI INSIEME DOBBIANO INSISTERE AFFINCHE' CIò AVVENGA PRESTO

Ho un quotidiano on line ed ogni volta che devo aggiornarlo  C'E' DA ESAURIRSI.

QUESTA SERA AVEVO AGGIORNATO TRE NOTIZIE CON RELATIVE FOTI E ARTUICOLI  ED HO PERSO TUTTO. LAVORO E TEMPO SPRECATO

 Sto tornanto alla PRECEDENTE VERSIONE  EVO 8 -

PER MICHELE G. Ho letto che hai un sito da oltre 600 pagine E TI CHIEDO:quando esportavi il progetto con la vecchia versione i tempi eranmo lunghissimi come accadeva a me, o c'è qualcosa che io non mettevo in atto per rendere l'esportazione più veloce?

Usavo naturalmete l'opzione:esporta solo i filE modificati:ma anche in questo caso impiegavo più di un'ora.

ASPETTO UNA TUA RISPOSTA. 

no i tempi erono veloci al max 5 minuti e poi partiva l'upolad

ora devo aspettare anche 1/2 ora prima che l'upload parta