Pagina 1 di 4 1 2 3 ... ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 32
  1. #1
    Utente di HTML.it L'avatar di Neocron
    Registrato dal
    Jul 2002
    Messaggi
    524

    [Flash Mx Pro 2004] LoadVars();

    è da flash mx che faccio a botte con questa classe, andrea lo sa bene ehhehe, non c'e' speranza per me di riuscire ad utilizzare unoscript con sendandload e riuscire ad utilizzare quel metodo.

    In uno script riuscii con sendandload ad inviare varibili a un file php, poiche send senon ricordo maleera buggato...

    questo è l'actioscript

    codice:
    var lv = new LoadVars();
    var vlobj = new Object();
    lv.ciao = 4;
    lv.onLoad = function(success) {
    	if(success){
          _root.testo.text = vlobj.blublu;
    	}else{
          _root.testo.text = "errore";
    	}
    }lv.sendAndLoad("ciao.php",vlobj,"POST");
    questo è il php

    Codice PHP:
    <?php
    header
    ("Expires: Mon, 26 Jul 1997 05:00:00 GMT"); 
    header("Last-Modified: ".gmdate("D, d M Y H:i:s")." GMT"); 
    header("Cache-Control: no-store, no-cache, must-revalidate"); 
    header("Cache-Control: post-check=0, pre-check=0"false); 
    header("Pragma: no-cache");
    print 
    'blublu='.(10+$_POST['ciao']);
    ?>

    non funziona nulla, non mi scrive nemmeno error nel campo di testo...

  2. #2
    Direi che l'onLoad lo devi assegnare a vlobj, visto che i dati vengono caricati li.

    Prova quindi così

    var lv = new LoadVars();
    var vlobj = new LoadVars();
    lv.ciao = 4;
    vlobj.onLoad = function(success) {
    if(success){
    _root.testo.text = this.blublu;
    }else{
    _root.testo.text = "errore";
    }
    }lv.sendAndLoad("ciao.php",vlobj,"POST");

    Comunque 'sta storia del send buggato me la dovete spiegà...se è riferito al fatto che aprisse una nuova finestra del browser...a quel che mi risulta non era affatto un bug ma era stato creato apposta così

  3. #3
    discussione gia' fatta ... link di Macromedia stessa gia' segnalati e altro ancora ...


    If the target parameter is specified, the server's response is displayed in the browser frame window named target. If the target parameter is omitted, the server's response is discarded.



    Il presunto "bug" era sul fatto che non c'era verso di NON far aprire quella finestra di ritorno, poi forse l' hanno corretto.

    @ Neocron
    codice:
    var lv:LoadVars = new LoadVars();
    lv.ciao = 4;
    lv.onLoad = function(success) {
    	if(success){
    		_root.testo.text = this["blublu"];
    	}
    	else{
    		_root.testo.text = "errore";
    	}
    }
    lv.sendAndLoad( "ciao.php", lv );
    // "POST" non serve, e' il default
    // l' Object() non serve .. torna tutto su lv
    // stampa comunque qualcosa col file .php ... 
    // ho avuto problemi in passato senza echare niente ....

    Io ad esempio utilizzo nello script PHP una variabile di controllo che diventa

    $myCheck = "error=".$myError
    echo $myCheck;

    .. oppure diventa l'output che mi interessa ...

    il tutto per controllare nell' onLoad che oltre ad aver caricato il php non abbia generato errori...


    if( success && this["error"] == undefined ) {
    // trallallero trallalla' ...
    }
    else {
    trace("errore in php" + this["error"])
    }
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  4. #4
    Originariamente inviato da andr3a
    Il presunto "bug" era sul fatto che non c'era verso di NON far aprire quella finestra di ritorno, poi forse l' hanno corretto.


    D'accordo, ho chiesto solo perchè ogni tanto qualche utente fuori la parola bug a casaccio ... magari sbaglia qualcosa lui ma la prima cosa che pensa è che sia un bug del programma
    Volevo semplicemente capire a cosa si riferiva Necron visto che sul loadVars.send di voci ne giravano svariate

    // stampa comunque qualcosa col file .php ...

    Guarda che lui nel php qualcosa stampa, in fondo c'è un print

    Per il resto...non so quale sia il suo caso, io personalmente delle volte (ad esempio se si tratta di un bel po' di dati) preferisco farmi due oggetti diversi per l'invio e la ricezione, ma chiaramente è un'opinione personale

  5. #5
    Utente di HTML.it L'avatar di Neocron
    Registrato dal
    Jul 2002
    Messaggi
    524
    andrea credimi, non so come ringraziarti .
    Se un geniaccio


    x Broly: se cerchi bene tra i post trovi altre persone che lo hanno giudicato bug, anche su un articolo di andrea c'e' scritto www.3site.it se poi ad oggi non è è piu' pazienza.

  6. #6
    Originariamente inviato da Broly
    Guarda che lui nel php qualcosa stampa, in fondo c'è un print
    ehm .. lol , il php non l'avevo nemeno visto



    Originariamente inviato da Broly
    Per il resto...non so quale sia il suo caso, io personalmente delle volte (ad esempio se si tratta di un bel po' di dati) preferisco farmi due oggetti diversi per l'invio e la ricezione, ma chiaramente è un'opinione personale
    dipende, potresti anche usare gli stessi nomi in invio e ricezione e tenerti l'oggetto sempre aggiornato o usare, appunto, sempre gli stessi nomi ... cmq dipende sempre dal tipo di scambio dati ma io di solito se posso evitare variabili in piu', visto che di solito non ne devo controllare 10 ma 100 ... evito volentieri
    [ anche la gestione della memoria dovrebbe essere migliore ]
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  7. #7
    Originariamente inviato da Neocron
    x Broly: se cerchi bene tra i post trovi altre persone che lo hanno giudicato bug, anche su un articolo di andrea c'e' scritto www.3site.it se poi ad oggi non è è piu' pazienza.
    Come già detto sopra, se ci fosse davvero un bug ogni volta che lo dice un utente del forum, Flash dalla prossima versione dovrebbero chiamarlo Grovier

    Andr3a, come dicevo prima questione di scelte, del resto dipende da quante cose uno deve inviare e ricevere e come si trova meglio a gestirle
    Come ho già detto dipende dalle situazioni, nemmeno io ho un metodo 'fisso', a seconda delle situazioni mi gestisco dati & c in un certo modo, era per segnalare anche che comunque entrambe le soluzioni sono corrette , poi magari uno si trova meglio a gestire molte variabili in un oggetto solo e un altro preferisce averne due

  8. #8
    Originariamente inviato da Broly
    Come già detto sopra, se ci fosse davvero un bug ogni volta che lo dice un utente del forum, Flash dalla prossima versione dovrebbero chiamarlo Grovier
    perche' non e' gruvier l' AS ?? ... io dico di si, ci sono troppe incongruenze e vedi Negatyve che m'ha lasciato a bocca aperta scavalcando il private come se fosse una var da Stage ...


    Tornando al discorso del bug .. magari correggo l'articolo ma ci tengo a precisare, prima che vengano fuori altre insinuazioni su cosa ho pensato o detto, che nel mio sito c'e' scritto questo:


    Il baco di send e' proprio quello di non passare alcun parametro in POST ma di utilizzare solo il GET.


    .. e poi questo ...


    • se invia variabili, le invia ad altre pagine aprendole come nuove finestre del browser
    • le variabili inviate saranno comunque di tipo GET, anche se il manuale interno all' MX stesso dice che di default dovrebbero essere in POST
    • il default non effettua alcunche', rendendo necessaria la giusta sintassi comunque non corrispondente a quanto richiesto



    A me sembra diverso da dire send e' buggato perche' non invia .. sembra un altro tipo di discorso che era comunque vero per MX, o perlomeno vero in quella circostanza o con quel player , di qui i link a Macromedia citati all' inizio, fu una lunga discussione...


    Originariamente inviato da Broly
    poi magari uno si trova meglio a gestire molte variabili in un oggetto solo e un altro preferisce averne due
    io gestisco le stesse variabili su un solo oggetto, non il doppio sullo stesso, sarebbe inutile e confusionario non credi ??
    Aggiungo: grazie per avermi dato dell' imbeecille
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  9. #9
    Originariamente inviato da andr3a
    Tornando al discorso del bug .. magari correggo l'articolo ma ci tengo a precisare, prima che vengano fuori altre insinuazioni su cosa ho pensato o detto, che nel mio sito c'e' scritto questo


    Ora mi dici dove avrei fatto riferimento a te?
    Ho detto che MOLTI utenti, perchè sono MOLTI quelli che tirano fuori la parola bug assolutamente a caso


    A me sembra diverso da dire send e' buggato perche' non invia .. sembra un altro tipo di discorso che era comunque vero per MX, o perlomeno vero in quella circostanza o con quel player , di qui i link a Macromedia citati all' inizio, fu una lunga discussione...

    Infatti non ho mai detto che TU hai detto che il send è buggato perchè non invia



    io gestisco le stesse variabili su un solo oggetto, non il doppio sullo stesso, sarebbe inutile e confusionario non credi ??

    Infatti non ho detto nè che lo fai tu nè che lo faccio io.


    Aggiungo: grazie per avermi dato dell' imbeecille

    Ora dimmi dove ti avrei dato dell'imbecille, visto che non me sono accorto, ma a quanto pare tu hai delle doti di veggenza e soprattutto particolari modi di interpretazione di alcune frasi :quipy:
    Se poi mi illustri il criterio con cui le interpreti...almeno evito di darti dell'imbecille senza averne la minima intenzione

  10. #10
    [OT]
    Originariamente inviato da Broly
    ma a quanto pare tu hai delle doti di veggenza
    significa che non m'hai dato dell' imbecille ma stai per farlo ??? :di56: :di56:




    ... so 2avanti :adhone:
    [/OT]


    cmq ho corretto l'articolo .. ora dice:
    Il problema di send ( tengo a precisare che in questo momento con MX2004 le cose potrebbero essere state risolte ) e' proprio quello di non passare alcun parametro in POST ma di utilizzare solo il GET.


    ... poi magari tra un po' lo riscrivo o lo levo del tutto
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.