Win32prn

[Ash]

Hello,

 

I have just converted an xHarbour application to Harbour and find that win32prn is selecting A4 paper size by default.  Code fragment to initiate win32prn is:

      oPrinter           := Win32Prn():new( cPrinter )

      oPrinter:landscape := .F.

      oPrinter:formType  := DMPAPER_LETTER

      oPrinter:copies    := 1

      oPrinter:setPrintQuality( DMRES_MEDIUM )

 

This application has been in production for many years.

 

I have researched (googled) for an answer but to no avail. Has any of you had any issues like this one? Thanks.

 

Regards.

Ash

 

[Klas Engwall]

Hi Ash,

No, I have had no issues ... because I have never tried to use it :-)

But I can see in contrib\hbwin\hbwin.ch that all constants have a "WIN_"
prefix. So WIN_DMPAPER_LETTER and WIN_DMRES_MEDIUM are the Harbour
equivalents of what you have been using in xHarbour.

xHarbour is very Windows oriented. Harbour, on the other hand, supports
many more platforms, so it has to be more specific when it comes to
platform specific function names, constants etc.

Didn't the compiler complain about not finding the constants? Or are
your compiler switches very forgiving?

Regards,
Klas

[Ash]

Hello Klas,

I use the following compiler switches:

-es0 -gc3 -m -a -mt -kd

I recompiled the whole system but saw no error messages regarding DMPAPER_LETTER either at compile or at run time. I use win32prn.ch file in my system. I tested with formType := 1, but that didn't help either.

To xHarbour, until a solution is found.

Regards.
Ash

[Massimo Belgrano]

post a reduced sample, able to run  for not include the complexity of your program in the problem
this sample will help other people helping your in this imo bad described problem

--
--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Massimo Belgrano
Delta Informatica S.r.l. (Cliccami per scoprire ) 

[Klas Engwall]

Hi Ash,

> I use the following compiler switches:
>
> -es0 -gc3 -m -a -mt -kd

Yes, very forgiving, as I suspected

You are using the default, very low warning level by not using any -w<n>
switch at all, and you accept that compilation continues whatever errors
there are by using -es0 switch. Set both to 2 to get a fair chance of
catching errors and warnings or errors and ambiguities will creep into
your executables without you seeing them.

> I recompiled the whole system but saw no error messages regarding
> DMPAPER_LETTER either at compile or at run time. I use win32prn.ch file
> in my system. I tested with formType := 1, but that didn't help either.

Harbour has no win32prn.ch file except in the xhb contrib, and it has
this comment at the top:

/* ------------------------------- */
/* Deprecated constants and macros */
/* ------------------------------- */

And the constants from it are thus not used anywhere in Harbour. The
WIN_ prefixed constants I mentioned yesterday are in hbwin.ch

> To xHarbour, until a solution is found.

It seems you are using constants that were meant for the version of the
Win32Prn class that exists in xHarbour, not the one for Harbour. And, by
the way, in Harbour Win32Prn exists for compatibility in the xhb contrib
and does not use the win32prn.ch header file at all.

The hbwin contrib has Harbour's official version of the class, and it is
called Win_Prn, not Win32Prn, and it uses the hbwin.ch header file.

So I think you will have to dig into this versionitis problem and make
sure that your constants match the source code of the class that you
actually use.

Regards,
Klas

[Ash]

Hello Massimo,

Here we go.

Same results with Win_Prn().

Regards.

Ash

#define DMPAPER_LETTER                 1
#define DMRES_MEDIUM                   ( -3 )

function main()

LOCAL oPrinter

   oPrinter           := Win32Prn():new( GetDefaultPrinter() )

   oPrinter:landscape := .F.
   oPrinter:formType  := DMPAPER_LETTER
   oPrinter:copies    := 1
   oPrinter:setPrintQuality( DMRES_MEDIUM )

   IF ! oPrinter:create()
      alert( "Cannot create device context" )
   ENDIF

   alert(xtoc(oPrinter:landscape)) // F
   alert(xtoc(oPrinter:formtype))  // p@
   alert(xtoc(oPrinter:copies))    // ??

   return nil

[Ash]

Hello Klas,

My application does not compile with -es2 and -w2.  I will use -es2 instead of -es0 for now ( application compiles OK with -es2) and clean up the code for -w2 over time.

I have posted a reduced sample in this thread showing bad data in 'formType' variable. I think this could be the reason for printer defaulting to A4 paper size.

Many thanks for your clear explanation.

Regards.

Ash  

[Klas Engwall]

Hi Ash,

> My application does not compile with -es2 and -w2. I will use -es2
> instead of -es0 for now ( application compiles OK with -es2) and clean
> up the code for -w2 over time.

OK, it is a good start. If you cannot use -w2 right now it can still be
useful to set it temporarily when searching for reasons for problems
like this and then turn it off again until you find the time to clean
the rest of the application.

> I have posted a reduced sample in this thread showing bad data in
> 'formType' variable. I think this could be the reason for printer
> defaulting to A4 paper size.

There are a few things you could test. First, compile and run this
modified version of your sample (link with hbwin.hbc only and skip hbct
and xhb):

#define DMPAPER_LETTER 1
#define DMRES_MEDIUM ( -3 )

function main()
LOCAL oPrinter

oPrinter := Win_Prn():new( win_PrinterGetDefault() )

oPrinter:landscape := .F.
oPrinter:formType := DMPAPER_LETTER
oPrinter:copies := 1
oPrinter:setPrintQuality( DMRES_MEDIUM )

IF ! oPrinter:create()
alert( "Cannot create device context" )
ENDIF

? oPrinter:landscape // F
? oPrinter:formtype // 1
? oPrinter:copies // 1

return nil

I get the proper formtype 1 and also the proper number of copies.

Then 1) remove the #define's, 2) add #include "hbwin.ch" and 3) prefix
the two constants with WIN_

I get the proper results again.

You could also borrow the contrib\hbwin\tests\prn1.prg example, change
the oPrinter:FormType setting to letter around line 39 to
WIN_DMPAPER_LETTER, and see what happens. I bet that will work too :-)

Regards,
Klas

[Ash]

Hello Klas,

Interesting!

I confirm that your program works here as you stated - F/1/1. But when I change the function name from Win_prn to win32prn (my application is using win32prn()), I get F/256/1. 256 is defined as DMPAPER_USER in both win32prn.ch and hbwin.ch header files. I was wrong in assuming that the printer was asking for A4 paper. The printer must have been asking for user defined paper via its manual feeder.

The simplest way to get this to work is to use win_prn() instead. I'll test and report back in the next few days.

Thanks again.

Ash

P.S. Would you agree that Harbour's win32prn() is flawed?

[Przemyslaw Czerpak]

Hi,

XTOC() convert numbers to binary representation of IEEE758 double
values. For sure it's not human readable. Fix you example code and
then tell us what is your problem.

BTW Harbour respects windows printer default setting and xHarbour
doesn't. Is it your problem?

best regards,
Przemek

> > 2015-01-08 5:33 GMT+01:00 Ash <jun...@gmail.com <javascript:>>:

> >> Unsubscribe: harbour-user...@googlegroups.com <javascript:>

> >> Web: http://groups.google.com/group/harbour-users
> >>
> >> ---
> >> You received this message because you are subscribed to the Google Groups
> >> "Harbour Users" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an

> >> email to harbour-user...@googlegroups.com <javascript:>.

> >> For more options, visit https://groups.google.com/d/optout.
> >>
> >
> >
> >
> > --
> > Massimo Belgrano

> > Delta Informatica S.r.l. (*Cliccami per scoprire
> > <http://www.deltain.it/mbelgrano>*)

[Ash]

This is not helpful.

Regards.

Ash

[Przemyslaw Czerpak]

Really?
I thought my message fully explains the problem and is much
better then set of messages with your wrong imaginations about
Harbour behavior which may confuse other users.
So if I'm wrong then please correct me or just simply send
the message that I'm right and subject is closed.

[Itamar Lins]

Hi!
Harbour Viktor fork add small fix for compatibility with xHarbour.

2015-01-08 16:56 UTC+0100 Viktor Szakats (vszakats users.noreply.github.com)   * contrib/xhb/xhwinprn.prg     ! Win32Prn() fixed xhb compatibility       See: https://groups.google.com/d/msg/harbour-users/1XLc_vPEUhw/XKtb9ibFkLMJ

Best regards, Itamar M. Lins Jr.

[Ash]

Hello Przemek,

What I meant was that I didn't understand your response. Please do not take offence.

From xHarbour's Language Reference the desciption of XTOC() is:

XtoC()
Converts values of data type C, D, L, M, N to a string.

Now if XTOC() works differently in Harbour, I wasn't aware of the change. My later tests didn't use this function for displaying the contents of the variables in question.

I have since changed my source code to as shown below and everything works. 

From:

      oPrinter           := Win32Prn():new( cPrinter )

To:

#ifdef __XHARBOUR__

      oPrinter           := Win32Prn():new( cPrinter )

#else
      oPrinter           := Win_Prn():new( cPrinter )
#endif

What would your assessment be in this situation?

Regards.
Ash

[elch]

hello Ash,

I confirm that your program works here as you stated - F/1/1. But when I change the function name from Win_prn to win32prn (my application is using win32prn()), I get F/256/1. 256 is defined as DMPAPER_USER in both win32prn.ch and hbwin.ch header files. I was wrong in assuming that the printer was asking for A4 paper. The printer must have been asking for user defined paper via its manual feeder.

looked into Harbour source ( 'contrib/xhb/xhwinprn.prg' ) :

METHOD Create() CLASS WIN32PRN

IF ::PaperLength > 0 .AND. ::PaperWidth > 0

::FormType := WIN_DMPAPER_USER

ENDIF

RETURN ::win_Prn:Create()

so maybe this is your case, check ::FormType before and after ::create()

---

BTW, related to a former post:

with switch '-a' you never will see any possible missing '#define' during compile,

as such will be IMHO assigned in that case as a MEMVAR ...

best regards

Rolf

[Ash]

Hello Rolf,

Looks like you have identified the area that needs attention.

Regards.

Ash

Before create():
PaperLength      2794
PaperWidth       2159
landscape         .F.
formtype            1
copies              1

After create():
PaperLength      2794
PaperWidth       2159
landscape         .F.
formtype          256
copies              1

-----Code------

#define DMPAPER_LETTER                 1
#define DMRES_MEDIUM                   ( -3 )

function main()
LOCAL oPrinter

    oPrinter           := Win32Prn():new( GetDefaultPrinter() )  

    ? oPrinter:PaperLength
    ? oPrinter:PaperWidth
    ? oPrinter:landscape
    ? oPrinter:formtype
    ? oPrinter:copies

    oPrinter:landscape := .F.
    oPrinter:formType  := DMPAPER_LETTER
    oPrinter:copies    := 1
    oPrinter:setPrintQuality( DMRES_MEDIUM )

    IF ! oPrinter:create()
       alert( "Cannot create device context" )
    ENDIF

    ? oPrinter:PaperLength
    ? oPrinter:PaperWidth
    ? oPrinter:landscape
    ? oPrinter:formtype
    ? oPrinter:copies

    return nil

[Przemyslaw Czerpak]

On Thu, 08 Jan 2015, Ash wrote:

Hi,

> >From xHarbour's Language Reference the desciption of XTOC() is:

> *XtoC()Converts values of data type C, D, L, M, N to a string.*

Exactly.
But it's not human readable string. Just like in original CT3 library.

> Now if XTOC() works differently in Harbour, I wasn't aware of the change.
> My later tests didn't use this function for displaying the contents of the
> variables in question.

To clarify. XTOC() in CT3, Harbour and xHarbour works in exactly the
same way. It converts numbers to 8 bytes strings with IEEE758 double
values so it's binary data. Harbour does not work differently then
original CT3. It was the reason why your result looked strangely.

> I have since changed my source code to as shown below and everything
> works.
> From:
> oPrinter := Win32Prn():new( cPrinter )
>
> To:
>
> #ifdef __XHARBOUR__
> oPrinter := Win32Prn():new( cPrinter )
> #else
> oPrinter := Win_Prn():new( cPrinter )
> #endif
>
> What would your assessment be in this situation?

There is one important difference between Harbour and xHarbour
Win32Prn/Win_Prn objects.
In Harbour at startup printer settings are read from the system
so the object is initialized in the same way as default setting
in your printer configuration.
What you see in your corrected test is what system returned for us.
In xHarbour printer settings are ignored and Win32Prn() object is
always initialized with fixed values regardless of system settings
and printer capabilities.
Now (when this is clear I hope ;)) can you tell me why it creates
problem for you?
What is your expected behavior?

best regards,
Przemek Czerpak

[Ash]

Hello,

To clarify. XTOC() in CT3, Harbour and xHarbour works in exactly the
same way. It converts numbers to 8 bytes strings with IEEE758 double
values so it's binary data. Harbour does not work differently then
original CT3. It was the reason why your result looked strangely.

You are correct.
The information in xHarbour Language Reference is not complete and in some ways misleading. I should be using CSTR() instead - it does what I thought XTOC() did.

There is one important difference between Harbour and xHarbour
Win32Prn/Win_Prn objects.
In Harbour at startup printer settings are read from the system
so the object is initialized in the same way as default setting
in your printer configuration.
What you see in your corrected test is what system returned for us.
In xHarbour printer settings are ignored and Win32Prn() object is
always initialized with fixed values regardless of system settings
and printer capabilities.
Now (when this is clear I hope ;)) can you tell me why it creates
problem for you?
What is your expected behavior?

 

I was expecting WIN32PRN() to perform as it does in xHarbour. Since it didn't, I made a simple code change in my application to overcome the issue.

The application is working well (around 2 times faster) in a LAN setting with 15+ users.  Early days, however.

Regards.

Ash

[Pedro MT]

Hi,

I have a console system that uses the libs (gtwvg/ gtwvt / gtwin) ... in this system, I have
the following function:

*- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -
FUNCTION CopyPaste(nOpc)

LOCAL nBits, lIsKeyCtrl

nBits := hb_GtInfo( HB_GTI_KBDSHIFTS )
lIsKeyCtrl := ( nBits == hb_BitOr( nBits, HB_GTI_KBD_CTRL ) )

DO CASE
CASE nOpc==1 && CTRL + C / Copy
IF lIsKeyCtrl
IF GetActive() != NIL
hb_gtInfo( HB_GTI_CLIPBOARDDATA, Transform( GetActive():VarGet(), "" ) )
Else
hb_gtInfo( HB_GTI_ACTIVATESELECTCOPY )
Endif
Endif
CASE nOpc==2 && CTRL + V / Paste
IF lIsKeyCtrl
__KeyBoard( hb_gtInfo( HB_GTI_CLIPBOARDDATA ) )
Else
KSetIns()
Endif
ENDCASE

RETURN
*- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -

The problem is that at random to copy and insert mode does not work. I do not mind so much the
"copy", if severe that the insert mode does not work at times. In the editing of memo fields
directly insert mode never works.

Thank you for any help!

================================================================================================
Spanish
================================================================================================

Tengo un sistema de consola que utiliza la libs wvtwg... en éste sistema, tengo la siguiente
funcion:

*- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -
FUNCTION CopyPaste(nOpc)

LOCAL nBits, lIsKeyCtrl

nBits := hb_GtInfo( HB_GTI_KBDSHIFTS )
lIsKeyCtrl := ( nBits == hb_BitOr( nBits, HB_GTI_KBD_CTRL ) )

DO CASE
CASE nOpc==1 && CTRL + C / Copy
IF lIsKeyCtrl
IF GetActive() != NIL
hb_gtInfo( HB_GTI_CLIPBOARDDATA, Transform( GetActive():VarGet(), "" ) )
Else
hb_gtInfo( HB_GTI_ACTIVATESELECTCOPY )
Endif
Endif
CASE nOpc==2 && CTRL + V / Paste
IF lIsKeyCtrl
__KeyBoard( hb_gtInfo( HB_GTI_CLIPBOARDDATA ) )
Else
KSetIns()
Endif
ENDCASE

RETURN
*- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -- - - -

El problema es que aleatoreamente el copiar y el modo insert no funcionan. No me importa tanto
el "copiar", si es grave que no funcione por momentos el modo insert. En la edición de los
campos memo directamente el modo insert no funciona nunca.

Gracias por cualquier ayuda!

Salu2!!!
Pedro
pe...@lawebdepedro.com.ar
*Lo que hacemos en la vida tiene eco en la eternidad

Usando The Bat! v5.4 en Windows XP 5.1 Build 2600 Service Pack 3
============================================================
The Bat! El MEJOR cliente de e-mail!
Bajelo de http://www.ritlabs.com/the_bat/

[Massimo Belgrano]

If you post  autonomous sample i try run

--

Massimo Belgrano
Delta Informatica S.r.l. (Cliccami per scoprire ) 

[Daniele Campagna]

IIUC you are exchanging data with some other Windows programs (I wrote a
custom copy/paste for data from a memofield to another memofield in the
same program, this is not complicated). I too experienced the same
problem, in a xHarbour program. It seems that the Windows clipboard acts
strangely. I never found a conclusive explanation. I tried some c-level
functions (from HWGUI and from WHAT32) but the problem from time to time
arises. Good to know that HB_GTI_CLIPBOARDDATA too behaves the same.
Keep us informed!
Dan

[José Quintas]

My code to Ctrl-C, Ctrl-V, and other things:

hb_gtInfo( HB_GTI_INKEYFILTER, ;
{ | nKey |

LOCAL nBits, lIsKeyCtrl
nBits := hb_GtInfo( HB_GTI_KBDSHIFTS )
lIsKeyCtrl := ( nBits == hb_BitOr( nBits, HB_GTI_KBD_CTRL ) )

SWITCH nKey
CASE HB_K_CLOSE
RETURN K_ESC
CASE K_MWBACKWARD
RETURN K_DOWN
CASE K_MWFORWARD
RETURN K_UP
CASE K_RBUTTONDOWN
RETURN K_ESC
CASE K_RDBLCLK
RETURN K_ESC
CASE K_TAB
RETURN K_DOWN
CASE K_SH_TAB
RETURN K_UP
CASE K_CTRL_V
IF lIsKeyCtrl
hb_GtInfo( HB_GTI_CLIPBOARDPASTE )
RETURN 0
ENDIF
CASE K_CTRL_C

IF lIsKeyCtrl
IF GetActive() != NIL
hb_gtInfo( HB_GTI_CLIPBOARDDATA, Transform(
GetActive():VarGet(), "" ) )

RETURN 0
ENDIF
ENDIF
ENDSWITCH
RETURN nKey
} )

José M. C. Quintas