Visualizzare su JLabel dove si trova il file .jar

[andbin]

Non è quello che succede nel codice attuale? Il catch di UnsupportedEncodingException sta proprio nel ButtonCADActionPerformed.

Ma c'è il throws UnsupportedEncodingException. QUESTO conta per il chiamante. È perfettamente lecito dichiarare una eccezione checked con il throws anche se quel metodo NON la lancia fuori. Questo perché il throws serve solo per avvertire di un possibile, potenziale, "pericolo" di una eccezione.

In senso generale (non è il tuo caso poiché il metodo è privato) un metodo può dichiarare una eccezione checked ma non lanciarla mentre poi in una sottoclasse che ridefinisce quel metodo può davvero realmente lanciarla. Ma il "pericolo" è già noto dalla super-classe quindi un chiamante che invoca il metodo polimorficamente sul tipo della super-classe è avvertito che una qualche implementazione del metodo può lanciare quella eccezione.
Questi sono concetti sulle eccezioni ... da studiare e sapere ....


P.S: soluzione: togli il throws UnsupportedEncodingException

[Gas75]

Questi sono concetti sulle eccezioni ... da studiare e sapere ....

Nulla in contrario, anzi.
Finora ho recuperato testi che trattano, se le trattano, le eccezioni relativamente ad argomenti diversi, in maniera trasversale; che sia giusto farle apprendere così non lo so, di certo io preferirei dei capitoli dedicati e poi la didattica trasversale me la faccio io appena acquisisco padronanza.
Addirittura il materiale didattico Oracle, che dovrebbe essere testo ufficiale per l'esame di certificazione OCA, parla di eccezioni, anzi di exceptions essendo in inglese, senza illustrare il perché se ne prevede una o l'altra. Il tutto è stato poi trattato "en passant" al corso che ho seguito perché argomento di coda...

[Gas75]

Purtroppo l'UTF-8 pare indispensabile per assegnare allo script di output il corretto nome, sennò ignora l'eventuale segno negativo di uno dei dati di input.
Ma appena lo ripristino, ecco che fioccano gli errori...

Nella versione console, tutto fila liscio invece, con o senza UTF-8.

---

Pare che nell'actionperformed del JButton che stampa lo script non arrivi questo controllo:

        Scanner lettore = new Scanner(InputReale.getText());
        if (CheckRealeSegno.equals(true)) {
            reale = -1 * lettore.nextInt();
        } else {
            reale = lettore.nextInt();
        }
        lettore = new Scanner(InputImg.getText());
        if (CheckImgSegno.equals(true)) {
            img = -1 * lettore.nextInt();
        } else {
            img = lettore.nextInt();
        }

[andbin]

Purtroppo l'UTF-8 pare indispensabile per assegnare allo script di output il corretto nome

Il charset (es. UTF-8, ISO-8859-1 ecc...) non c'entra nulla con il NOME del file. C'entra solo con il contenuto del file quando si tratta di "testo".

[Gas75]

Me ne sono accorto dopo, infatti ho modificato il messaggio...
Per qualche motivo cui sto indagando nel ButtonCADActionPerformed non arriva il controllo dei checkbox che gestiscono il segno degli input, anche inserendo nel metodo stesso il controllo che funziona nel metodo associato al Button che effettua i calcoli.
Se stampo in console i valori di input dopo il controllo dei checkbox, mi stampa i valori sempre positivi, che immagino siano quelli accettati nei textfield, ignorando gli if.

[Gas75]

Quei cicli if per gestire il segno tramite checkbox non funzionano.
Se sostituisco CheckRealeSegno.equals(true) con null != CheckRealeSegno, il segno viene cambiato sempre!
In pratica pare che le Checkbox siano isolate dal flusso del codice.