Newsgroup: it.comp.lang.visual-basic
Titolo: [NET] Errore creazione font per la stampa

Ciao a tutti,
in VS.Net 2003 ottengo il seguente messaggio di errore
An unhandled exception of type "System.ArithmeticException" occured in
system.drawing.dll
Additional information: Overflow or underflow in the arithmetic
operation
nel momento quando eseguo questa istruzione:
fntl = New Font("Courier New", 12)
dove fntl è dichiarato come
Dim fntl As Font
poco prima
Ottengo questo errore nella procedure di gestione dell'evento
PrintPage di un oggetto PrintDocument. Il fatto curioso è che se uso
un oggetto PrintPreviewDialog per l'anteprima invece di mandare
direttamente la stampa il tutto funziona bene.
Qualche idea in proposito ?
Ciao e grazie
Stefano "HappyMan" (Lago Maggiore - NO)
--
http://www.sgr.info
Email happyman69 (at) 
libero.it

SP1 di .net 2003 :) ??
No scherzo, non saprei come aiutarti se non dirti di andare
su ugidotnet ... li c'è gente - tra cui Corrado - che sicuramente
ti può indirizzare sulla risoluzione del problema.
Andrea

ti puň indirizzare sulla risoluzione del problema.
Ho postato anche su microsoft.public.it.dotnet.vb dopo aver scoperto
che tale problema si manifestava solo se stampavo su una stampante PDF
(per crearmi il relativo file).
Corrado Cavalli mi ha risposto riportandomi un post dato in un caso
simile e grazie a quel suggerimento con una ulteriore ricerca su
google ho trovato la soluzione.
Non so se definirlo un bug di net 2003, sicuramente č un comportamento
spiacevole della New Font.
Riporto la soluzione che ho scritto sull'altro ng.
Aggiungi questo namespace
Imports System.Runtime.InteropServices
Aggiungi questa declare
Declare Function _controlfp Lib "msvcrt.dll" Alias "_controlfp" (ByVal
In_New As Integer, ByVal In_Mask As Integer) As Integer
Aggiungi questa sub
   Private Sub CheckFPU()
      Const _MCW_EW = 524319
      Const _EM_INVALID = 16
      _controlfp(_MCW_EW, _EM_INVALID)
   End Sub
Prima di ogni New Font chiami CheckFPU che rimette a posto i settaggi
inerenti la FPU, cosě da far contento il framework.
Ciao 
Stefano "HappyMan" (Lago Maggiore - NO)
--
Personal Web 
http://www.sgr.info
Email happyman69 (at) 
libero.it

In_New As Integer, ByVal In_Mask As Integer) As Integer
Questo, e altri post che leggo in giro, non fanno altro che
rafforzarmi l'idea che per ancora un po' di tempo .NET e' e sara'
principalmente spazzatura.
-- 
ciao, hal

principalmente spazzatura.
Io fino ad ora ero riuscito ad evitare l'incontro con (vb).net ma
essendomi arrivata una richiesta di un software in tale linguaggio mi
sono adeguato: non è stato questo problema (che pure mi ha fatto
perdere parecchie ore) a crearmi una cattiva idea del framework ma le
prestazioni. 
Sviluppo su un Athlon XP 2000+ con 768 MB di RAM ma vedere i miei form
(che includono una datagrid) apparire in modo tutt'altro che immediato
(eufemismo) è ogni volta un pugno nello stomaco. Non mi interessa
sapere che la seconda volta che apro lo stesso form questo appare
veloce, mi urta il fatto che anche un programma che apre un form vuoto
con .net richiede almeno 10 MB di ram (per la CLR).
In Microsoft hanno fatto un notevole lavoro di astrazione e
ingegnerizzazione nel creare quella moltitudine di classi (bisogna
riconoscerlo), con il doppio risultato da una parte di complicare ciò
che prima era semplice (vedi stampare o l'accesso ai dati) e
dall'altra di rendere "granulare" le possibilità di sviluppo, rendendo
possibile l'accesso a praticamente tutti gli aspetti del s.o. (cosa
che in VB6 era complicato).
Peccato che come sviluppatore C++ fossi già arrivato al minimo della
"granularità" :-/
Non sarà un caso che, come Microsoft stessa ammette, il passaggio a
.net da parte degli sviluppatori è moolto più lento di quanto si
aspettassero.


aspettassero.
Non ne dubito.
Tanto per rubare una battuta di Oreglio:
non capire un c@%%0 per non capire un c@%%0, mi tengo ancora strette
la vecchia MFC e ATL/WTL.
-- 
ciao, hal