PDA

View Full Version : Virtual Print Engine (VPE) and Unicode



Frank Cheng
25-Feb-2020, 05:44 PM
Does anyone have any experience upgrading their VPE reports to be Unicode/UTF8 compatible?

We have many VPE reports. Converting them for DF 20 seems pretty PITA.

Frank Cheng

starzen
25-Feb-2020, 06:31 PM
havent had much time yet but here are some of the things i see

there are only a few functions that are impacted (about 70)
they define the same function but have a U appended (VpeLicense vs VpeLicenseU)
and use UTF-16

so hopefully all it takes is to change the underlying class functions and all just compiles and runs ... (we will see)

Arnold
26-Feb-2020, 02:19 AM
Frank,

as far a I know, VPE doesn't support UTF. The only thing I changed, in my code is, before printing a value with VPE is doing the next line:



Move (Utf8ToAnsi(sValue)) to sValue


I still use the DDL version of VPE and not the ActiveX, I tested with VPE 7.2 32 and 64-bit in combination with DF 20.0

Frank Cheng
26-Feb-2020, 07:30 AM
Arnold,

I understand how converting UTF8 to ANSI works. However that seems to defeat the purpose of having UTF8 in the first place. Let's say I want to print a report that has text from different languages (spanish, chinese, and korean), Utf8ToAnsi is probably going to turn at least 2 out of 3 languages into a bunch of question marks (MultiByteToWideChar/WideCharToMultiByte with CP_UTF8/CP_ACP).

That's why DF 20 is using the "W" version of all the APIs instead of calling the "A" version with Utf8ToAnsi in the first place.

Frank Cheng

Arnold
26-Feb-2020, 07:39 AM
Frank,

I understand your point but as far as I know VPE doesn't support Unicode, so that will be problem anyway.

starzen
26-Feb-2020, 08:39 AM
Did some more research and testing

VPE does have unicode functions that accept UTF-16 character strings
i was able to simply modify our packages to use the 'U' decorated functions and pass the strings as WString

but internally VPE uses Ansi strings and will convert the data passed to Ansi so it is really not Unicode capable

from looking at their responses (last one was in August 2019) it looks like there isnt anything happening at the moment

Peter van Mil
26-Feb-2020, 09:23 AM
Form the VPE Forumin August 2019:



How can I display Chinese characters with VPE 6.0?

This is not possible. VPE does not support Unicode.

Edgard
28-Feb-2020, 05:58 AM
Hi,

Between the devil and the deep sea.

Honestly, I can't understand, because we have to go through all these disorders.

It is not the first time that I have mentioned this subject.Winprint -> Winprint2 (without serialized graphics) or DR (Same) = VPE (is that the reason you use VPE?).

I did some tests, with 32-bit VPE, hoping to remove obsolete Winprint commands.

Some graphic descriptions are extremely small and, for some reason, the command via OCX (I have not tested the DLL), does not change the font size.

Their support is simply disappointing:

They don't recognize and don't know how Dataflex works, nor do they seem interested in it.

It would not be better to make a commotion by begging that the existing resources in the winprint be propagated in a Winprint3 or DR, because we would be working with a single tool:

DF20 or 21 in 64 bits?

Best Regards

starzen
28-Feb-2020, 06:10 AM
VPE is a very good print engine.

you must be doing something wrong if you cant change font size.

A long time ago we decided to use VPE for our application development because it was the only product available that allowed us to do all the complex reporting we do especially things like calendar printing etc.

Of course VPE is just a printing engine it doesnt know about reports, databases etc. So we spent a lot of time and created our document and reporting classes for VPE

RE: Their support is simply disappointing
You cant really expect a vendor of an ActiveX / DLL third party product to learn DataFlex and support DataFlex developers. The market is simply too small.

Another option is List & Labels. Years ago we were also looking at L&L but back then it didnt have the features we needed. Lately we started using L&L in a few projects.
The .net interface in L&L is much nicer than than the DLL interface you are using with DF though

Edgard
28-Feb-2020, 07:08 AM
Any interface will be more advanced than Winprint or Winprint2, frozen in time and replaced by DR7, which does not do what the past did.

I'm not asking for anything new, just compatibility, using DF resources. - Ok, was it an ADB-UTVECKLING DLL distributed in VDF6 until today or until when?

I will not add fuel to the fire, with Crystal Reports, which at the time had more graphic resources, fortunately, I did not use it.

Perhaps for many and for you, Winprint is no longer sufficient for your needs, forcing the use of third party resources.

I am conservative and prefer to use the resources available in our main development tool, where the fewer third parties are involved in basic functions, the less problems we will have.

Grateful for the tip

wila
28-Feb-2020, 07:19 AM
Edgard,


I am conservative and prefer to use the resources available in our main development tool, where the fewer third parties are involved in basic functions, the less problems we will have.

I have heard other people using that same rhetoric and am frankly a bit baffled by it.
It is simply not always true!

If you are going to rebuild things in DataFlex that are already available as a external control then you are doing yourself -and your customers- a great disservice.
Not only are you going to have to support and extend something that you can just buy off the shelf, but you also won't be able to use new features that are part of the product when it gets an update/upgrade.
It also takes away time that you can spent on building the product your customers want/need.

You are building on top of the windows platform. DataFlex gives you the ability to use those building stones and gives you access to external controls built in other languages. Refusing to use that is throwing away a big competitive edge.

--
Wil

Peter van Mil
28-Feb-2020, 07:37 AM
Hi Edgar,

An older version of the VPE Library is based on Winprint commands. So if you really want it you can stick to these basic functions.

starzen
28-Feb-2020, 07:43 AM
RE: I am conservative and prefer to use the resources available in our main development tool, where the fewer third parties are involved in basic functions, the less problems we will have.

that is your choice of course and it depends on what you do and need

there isnt a single project we have been working on in the last 20 years that i could get away with only using what DataAccess puts in the toolbox

and just to be clear the same goes for any other dev language as well. When we use C# we also use lots of third party packages, same for Javascipt projects or Python projects

if i needed to build all these things myself i'd spend a lot of extra time building a tool that will possibly give me more problems than using a tool someone else dedicated all their time to

Garret Mott
28-Feb-2020, 08:06 AM
I certainly understand the hesitancy to use external products - especially after being badly burned by a company going out of business back when I was mostly programming in Visual Basic. That situation was one where I'd used a large group of their controls in the application & when they went under & I had to move to a later version of VB, I had to completely rewrite large chunks of my programs.

Using a product that is not so interwoven is certainly safer, and as Michael says, DF simply does not offer everything needed. Back in CM days, when expectations were far lower, one could do it with 100% DF. That is just no longer the case.

Edgard
28-Feb-2020, 03:55 PM
Here's the X of the question.

A third party creates the Winprint-based tool, because DAW dropped the ball.:confused:

I cannot say that the VPE solution is equal to or greater than Winprint.
Example: pie chart with slice, positioning controls and page jump very different from Winprint, which is why I think Michael created the class.

But its alright. . .

I am a losing vote to Garrett's opinion or beyond. :D

Apparently, I will inevitably have to use VPE and, if that third-party company ceases to exist, do what. . .

We remade and remade what worked in the past.:mad:

Regards

starzen
28-Feb-2020, 04:06 PM
Edgard

take a look at List & Labels also. Main difference is you can use a visual design tool for it

VPE is very powerful, there really isnt much you cant do with it but you cant design reports visually

starzen
1-Mar-2020, 07:24 AM
A small update

we recompiled our classes for VPE and even without any changes it still runs and prints properly, As long as you dont use any extended characters of course.
if you use extended characters then you end up with one or multiple (depending on the byte length for that character) incorrect characters.

so the above is the same code that still uses standard DF strings and passes them as a String to the external function and uses the VPE ANSI functions
We also have automatic OEM to ANSI translation behind the scenes in the classes.

so for us it will be as simple as
define the unicode functions from VPE using WString and change the internal calls to call the unicode functions instead and turn off the ansi translation (simple property)

obviously VPE at this moment internally does not actually support unicode but using the unicode function would make sure that it will work if they add the capability.

you could of course keep calling the ANSI functions and use Utf8ToAnsi to convert the strings before calling

Good news for anyone using our classes is that it should be completely transparent without any required changes except for a recompile