Forums

by johnmunro >> Mon, 20 Jan 2003 10:57:37 GMT

Our application needs to do image processing without a user interface, for example, painting a picture on another picture without there being any forms or controls involved.

There are two things preventing us from doing this. First of all, if we call drawPictureAt on a transient instance of Picture, we get a "window not created" exception. Secondly, these transient instances do not resize themselves to the size of the picture being placed on them (when the stretch property is set to ControlToPicture). We need to know the dimensions of the pictures in order to position them correctly.

Shouldn't it be possible to do this using just GDI API calls?

John Munro

---
Synergist Limited - Home of FileVision
The Bioscience Innovation Centre
Cowley Road, Cambridge, UK
CB4 0DS

Telephone: +44 (0) 1223 478200
Fax: +44 (0) 1223 477969
Email: john.munro@filevision.com
Web: http://www.filevision.com

The contents of this communication are confidential and are only intended to be read by the addressee. We apologize if you receive this communication in error and ask that you contact Synergist Limited immediately to arrange for its return. The use of any information contained in this communication by an unauthorized person is strictly prohibited. Synergist Limited cannot accept responsibility for the accuracy or completeness of this communication as it is being transmitted over a public network. If you suspect this message may have been intercepted or amended, please inform Synergist Limited.

by allistar >> Mon, 20 Jan 2003 22:26:31 GMT

I'm not sure about using GDI calls, I have a couple of suggestions:

- actually create the window but put it off screen so it can't be
seen. This will only work in a GUI type application.

- read the image into Jade and process it yourself by playing with the Binary. This shouldn't be too hard if the format of the image is easy, like BMP. There is a lot of freely available code out there for
reading (and writing) bmp files into a raw binary form. Then
manipulating it will be a matter of altering the binary. Overlaying
one picture onto another will be a metter of copying blocks of memory
of one Binary onto another (you could also do neat stuff like alpha blending etc.).

I have some C++ code for reading a BMP file into memory, if you would like it. If you can control the image type (say 24 bit BMP) then the process becomes much easier (as you don't have to shag around with
things like pallette tables).

John Munro

Regards,
Allistar.

------------------------------------------------------------------
Allistar Melville
Software Developer
Auckland, NEW ZEALAND

Greentree International,
Developer of Greentree Financial Software. ------------------------------------------------------------------

by CarlRanson >> Mon, 20 Jan 2003 23:14:56 GMT

Should be quite possible to do this with GDI calls.

You still need to create a device context to use any gdi related stuff, but you can use CreateCompatibleDC to make a memory device context and createCompatibleBitmap to make a bitmap you can draw into.

Then you can do whatever drawing calls you need (blitBit for instance) to make a drawing.

createCompatableDC http://www.msdn.microsoft.com/library/d ... us/gdi/bit maps_5a5h.asp

CreateCompatibleBitmap http://www.msdn.microsoft.com/library/d ... us/gdi/bit maps_1cxc.asp

And the following examples should get you started: http://www.msdn.microsoft.com/library/d ... us/gdi/bit maps_5y1x.asp http://www.msdn.microsoft.com/library/e ... s_7zfp.asp http://www.msdn.microsoft.com/library/e ... s_2b00.asp

good luck. CR

by allistar >> Mon, 20 Jan 2003 23:52:43 GMT

Good tip, the only issue I see is that you would then be limiting your application to be running on a Windows computer (which may not be an issue for you in the short term - will it in the future?)

Allistar.

------------------------------------------------------------------
Allistar Melville
Software Developer
Auckland, NEW ZEALAND

Greentree International,
Developer of Greentree Financial Software. ------------------------------------------------------------------

by JensRichnow >> Sun, 26 Jan 2003 6:59:47 GMT

I agree with Carl, using GDI should solve your problems. Years back I did lots of image manipulation in Jade primarily using GDI calls, and you can create stunning visual effects. As far as I remember, the only problem I had was with various Windows versions in terms of execution speed and taking processing resources.

I'm a bit surprised with the comment of the platform limitation. So far, Jade has been a development environment for the Windows platform. With the next major version release of Jade we will see the port to Linux. We will have to see whether there are limitation with respect to various Linux versions and for every Linux flavour the kernel version.

I just thought about the features which many, if not most, Jade applications today make them Windows-specific. There are the calls to common controls (file dialog for opening and saving files, colour picker), the widespread usage of external functions (to windows-specific libraries/ActiveX), probably some external methods, and---admittedly, I'm not sure about the next point---the underlying binding to the Windows GUI libraries for forms, controls, etc.. Many of these points can be implemented into Jade to make them perceivable platform 'independent'. If you think client-server application, there are many ways to make the client application platform-'independent'. And in the end, what choice do you have for a given problem, like the stated, which most probably cannot be solved with the existing 'native' Jade code base.

by allistar >> Sun, 26 Jan 2003 21:44:14 GMT

I agree with Carl, using GDI should solve your problems. Years back I did lots of image manipulation in Jade primarily using GDI calls, and you can create stunning visual effects. As far as I remember, the only problem I had was with various Windows versions in terms of execution speed and taking processing resources.

It's always fun going "under the hood" to implement things. Typically
the further down you go the longer it takes to develop, but the
execution speed is much faster. The more abstracted, the quicker development is but execution speed suffers.

I'm a bit surprised with the comment of the platform limitation. So far, Jade has been a development environment for the Windows platform. With the next major version release of Jade we will see the port to Linux. We will have to see whether there are limitation with respect to various Linux versions and for every Linux flavour the kernel version.

As long as it runs on X11/XFree86 then conpatability between linux distributions shouldn't be an issue.

I just thought about the features which many, if not most, Jade applications today make them Windows-specific. There are the calls to common controls (file dialog for opening and saving files, colour picker), the widespread usage of external functions (to windows-specific libraries/ActiveX), probably some external methods, and---admittedly, I'm not sure about the next point---the underlying binding to the Windows GUI libraries for forms, controls, etc.. Many of these points can be implemented into Jade to make them perceivable platform 'independent'. If you think client-server application, there are many ways to make the client application platform-'independent'. And in the end, what choice do you have for a given problem, like the stated, which most probably cannot be solved with the existing 'native' Jade code base.

My comment was more forward looking than it was a relection of the current situation. In the future I see other operating systems
becoming more mainstream, and I see Jade being utilised a lot more on
non Windows platforms. In particular when Jade 6 comes up I know I for one will be very interested in running a server on Linux. A lot of our clients share the same enthusiasm.

This doesn't stem from the usual anti-MS sentiment (well, not completely), but rather from a point of openness, stability,
performance and cost.

Anything I develop in Jade (or in C/C++ that interefaces to Jade) I
try and keep it as portable as possible, so that in the future if the market wants to use a different platform we don't have to bear any
major redevlopment costs. I have already made the mistake of using MFC and DCOM for a couple of our utilities which will need to be ported ni the near future to run on AIX and Linux.

Allistar.

------------------------------------------------------------------
Allistar Melville
Software Developer
Auckland, NEW ZEALAND

Greentree International,
Developer of Greentree Financial Software. ------------------------------------------------------------------