vector-based pictures (*.wmf, etc.)

For questions and postings not covered by the other forums
ConvertFromOldNGs
Posts: 5321
Joined: Wed Aug 05, 2009 5:19 pm

vector-based pictures (*.wmf, etc.)

Postby ConvertFromOldNGs » Fri Aug 07, 2009 11:48 am

by Jens Richnow >> Wed, 26 Jan 2000 22:09:35 GMT

Hi,

I wonder in as much JADE supports vector-based picture formats, with *.wmf as probably the simplest form. The painter allows one to read
*.wmf files. However, there is no support for saving a picture in this format. The ::convertPicture and and ::convertToFile methods only
support bitmaps.

Does JADE uses the standard Windows controls, especially Picture? If
yes, why is there no support for saving pictures---including all
drawings done onto it---in the Windows (Enhanced) Metaformat, which is easily done with VB. Or may be, it is still a hidden feature of JADE...

What I need to do is saving charts and graphs created with JADE in one
or the other vector-based picture format. Does anybody has done it
before and may share some ideas!?

Jens

ConvertFromOldNGs
Posts: 5321
Joined: Wed Aug 05, 2009 5:19 pm

Re: vector-based pictures (*.wmf, etc.)

Postby ConvertFromOldNGs » Fri Aug 07, 2009 11:48 am

by John Eyers >> Wed, 26 Jan 2000 22:37:07 GMT

I found, by just trying it, that icon, cursor and metafile images can be saved to a file declared as mode output and kind binary
simply by doing a file.writeBinary(image) where 'image' is the Binary picture content.

The file produced is in the correct format for an icon, cursor or metafile (depending on the original pcture type).

ConvertFromOldNGs
Posts: 5321
Joined: Wed Aug 05, 2009 5:19 pm

Re: vector-based pictures (*.wmf, etc.)

Postby ConvertFromOldNGs » Fri Aug 07, 2009 11:48 am

by Jens Richnow >> Thu, 27 Jan 2000 0:07:01 GMT

John,

thanks for this fast reply. I think I'm a step further. I can save the picture which I loaded to a file having the same picture format.
However, it does not save all the graphics and charts created on the picture control. I suppose I need to create a picture of the Picture control first, similar to ::createPicture(..), which, however, only returns bitmaps.

savePictureAsWMF() updating;
vars wmf :Binary;
file :File;begin

wmf := pic.picture;
create file;
file.mode := File.Mode_Output;
file.kind := File.Kind_Binary;
file.fileName := "C:\Jens\test.wmf";
file.writeBinary(wmf);
epilog
delete file;
end;

Thanks,

Jens

ConvertFromOldNGs
Posts: 5321
Joined: Wed Aug 05, 2009 5:19 pm

Re: vector-based pictures (*.wmf, etc.)

Postby ConvertFromOldNGs » Fri Aug 07, 2009 11:48 am

by Carl Ranson >> Wed, 26 Jan 2000 23:36:22 GMT

I agree that the meta file support in Jade is fairly sad. It's been frustrating to me on occasion that some things that are simple at the windows API level have been made very difficult to do in Jade.

You might find that there is an unpublished createMetaFile method on control, with paramters similar to createPicture.

But you didn't hear it from me :)

CR

ConvertFromOldNGs
Posts: 5321
Joined: Wed Aug 05, 2009 5:19 pm

Re: vector-based pictures (*.wmf, etc.)

Postby ConvertFromOldNGs » Fri Aug 07, 2009 11:48 am

by Jens Richnow >> Thu, 27 Jan 2000 0:24:11 GMT

Carl,

many thanks for this "secret" (I suppose, one could easily fill an
entire volume with JADE's unpublished features which would be a much appreciated third textbook probably distributed by word of mouth!). As with unpublished features one has to test what parameter they require
and what they return. For the parameter: it was happy with a Boolean and a String, but for the return type I have no clue.

I tried

pic.createMetaFile(true, "C:\Jens\test1.wmf");

which creates the right file format but without any original colour components and without any of the additonal drawings (done with
drawLine, etc.).

Regards,

Jens

ConvertFromOldNGs
Posts: 5321
Joined: Wed Aug 05, 2009 5:19 pm

Re: vector-based pictures (*.wmf, etc.)

Postby ConvertFromOldNGs » Fri Aug 07, 2009 11:48 am

by Carl Ranson >> Thu, 27 Jan 2000 1:11:26 GMT

You may want to check the autoRedraw property. I wouldn't be suprised if it effects this method.

I would think the return type is an integer or boolean result code.

Regards,
CR

ConvertFromOldNGs
Posts: 5321
Joined: Wed Aug 05, 2009 5:19 pm

Re: vector-based pictures (*.wmf, etc.)

Postby ConvertFromOldNGs » Fri Aug 07, 2009 11:48 am

by Eric Peachey >> Thu, 27 Jan 2000 1:23:25 GMT
with unpublished features one has to test what parameter they require and what they return. For the parameter: it was happy with a Boolean and a String, but for the return type I have no clue.

To find out more info about the methods on a class, add a method in a play schema to Class which does the following:


haha();

vars

m : Method;begin


foreach m in methods do
write m.makeHeader;
endforeach;
end;

Then write a simple workspace which does (if you're interested in the Control class):

Control.haha;

Run it and the list of method signatures will be written to the output viewer. It seems a harmless procedure but you shouldn't be using any of the hidden stuff as presumably it's hidden for good reason.

Eric in Dunedin

ConvertFromOldNGs
Posts: 5321
Joined: Wed Aug 05, 2009 5:19 pm

Re: vector-based pictures (*.wmf, etc.)

Postby ConvertFromOldNGs » Fri Aug 07, 2009 11:48 am

by Dean Cooper >> Thu, 27 Jan 2000 3:04:05 GMT
It seems a harmless procedure but you shouldn't be using any of the hidden stuff as presumably it's hidden for good reason.

You should be wary of using hidden RootSchema methods in production apps. Many methods are hidden because they are for system use only; others because they may be made available in a future release (possibly with different signatures or behaviour). As such, hidden methods are subject to change (or even removal) without notice. Many hidden methods are part of the internal RootSchema implementation and are not designed or intended to be part of the public interface. Using or reimplementing hidden methods can be dangerous as you may not be fully aware of their behaviour, the conditions under which they can/should be used, or any side-effects. Incorrectly reimplementing some hidden methods can adversely affect other RootSchema operations.

We would like to tighten up on this in a future release by separating hidden methods into system-only and unpublished methods. With a system-only classification, both the compiler and the kernel will be able to enforce that such methods are never accessed from user apps. Unpublished methods would still be available for use, although still subject to change.

Dean.


Return to “General Discussion”

Who is online

Users browsing this forum: No registered users and 23 guests