Hi

I'm currently working on a program to calculate regions from image files, to be used for skinning a program. It's still VERY beta (scroll bars are not yet implemented, for example :grin: ), but most of it is finished, and I wanted to know if there's any bugs that need correction, or suggestions of new features to be implemented, before I get to work on the scrollbars (it will need rewriting of my paint routines).

The regions are saved as raw files, using a RGNDATA structure. I have seen some tutorials on skinning windows (like Test Department's), but they only store the RECT data, and not the RGNDATAHEADER part. Is there any specific reason for this? (like a compatibility problem or so). I'm using ExtCreateRegion, that's why I prefer to store the whole structure (and so it can be used in the resource script, otherwise I would have to hardcode the filesize in the program, I think it's more versatile this way).

The program also allows you to manually edit the region data. I'm interested in any suggestions regarding how to improve the region editor.

EDIT: Deleted attachment (44 downloads). See bottom of thread.
Posted on 2003-08-29 15:30:56 by QvasiModo
It would be nice as an AddIn for RadASM, you could auto-update the resource file, saving the rgn resource in the RES folder.
Posted on 2003-08-29 15:44:30 by donkey
Very good idea, donkey! I thought only of adding it to the tools menu, but the addin approach is better. Added to the list :)

Will implement it a little later though, I want to make sure I finish the standalone version first, since in order to transform it into an addin I won't have to rewrite much code (like I did with the error lookup thing before).
Posted on 2003-08-29 15:52:11 by QvasiModo
I understand fully, I am doing the same thing with toolbar paint, I am developping it as a standalone app then at some later date I will convert it to an addin. I would suggest that you provide the possibility to have the filenames loaded by command line, that is what I did. The advantage is that you can keep the standalone app and just write an addin to plug in the filenames and start the standalone. Just my opinion but it is how I am planning to integrate TBPaint into RadASM.
Posted on 2003-08-29 16:06:59 by donkey
Yes, it's what I was just thinking of doing to convert it to an addin. Thanks for the commandline idea, it's a nice feature and will be easier for the conversion. :)
Posted on 2003-08-29 16:10:47 by QvasiModo
Well i wont pretend i fully see its uses, but the program is done nicely! Good work..

Perhaps you can show an example (simple sample) of its uses in a program? (I guess this is to do similar stuff as the RGN creator tool ?? )

I understand it is your intent for use with skinned windows, but Im not seeing how...
:NaN:
:stupid:
Posted on 2003-08-29 23:34:34 by NaN
Indeed, this program is similar to RGN creator tool... in face I made it because RGN creator didn't do exactly what I wanted :) . Besides I can't learn anything in programming if I don't code an example or two, and this seemed like a constructive way to learn about region GDI objects.

Here's a sample use of this program.

By precalculating the regions, you can use SetWindowRgn for custom window shapes (necessary for skinning with transparencies). There are several examples of this, including one by TD, but most of the stuff I have seen only stores the RECT structures (making it more difficult to use it the resource section), or calculated the regions on runtime (wich could be very slow if you have several images).

The region editor was added just to make some simple operations without having to whip out an hex editor to do it manually, or having to do it in your app.
Posted on 2003-08-30 13:44:30 by QvasiModo
The last version had a nasty bug when clicking "File -> New" that would cause a heap corruption.
Also I have implemented the scroll bars.

EDIT: Deleted attachment (32 downloads). See bottom of thread.
Posted on 2003-08-30 13:50:19 by QvasiModo
Thanks QvasiModo for sharing your RGN application. I also developed an RGNDATA generator but it's only a command line utility. BTW, my GenGUID1.2b application makes use of the SetWndowRgn api.
Posted on 2003-08-31 01:02:25 by Poimander
Thanks Poimander for your support :) (at least someone sees the point of this program :grin: )
I would like to see your RGNDATA app, it would be interesting to compare notes :)
Posted on 2003-09-01 09:55:14 by QvasiModo
Last beta version. I have no plans for further work on it, except for bug fixes and new feature suggestions. I'll be working on the RadAsm specific version of this.

EDIT: Uploaded attachment again. My mistake, it didn't compile well the manifest resource.

EDIT: Deleted attachment (16 downloads). See bottom of thread.
Posted on 2003-09-01 09:58:27 by QvasiModo
New update:

- Bugfix: one extra line was being added to the region, outside the image.
- Bugfix: transparent GIF pictures are now being loaded correctly.
- Bugfix: scroll bars are now being shown properly when the window was maximized and a new picture is loaded.
- Bugfix: the main window is now auto resized the the work area, not the screen size.

EDIT: Deleted attachment (13 downloads). See bottom of thread.
Posted on 2003-09-04 12:50:13 by QvasiModo
New bugfix, just the EXE this time (I'm not uploading the addins until I get the to work more or less decently).
The scrollbars were not working properly when clicking on them instead of dragging the thumb box.
Posted on 2003-09-06 14:21:02 by QvasiModo
Sorry to bring up an old thread :), but I have a suggestion for the app: you seem to be using a very slow method of creating the region data from the bitmap. If you replace the GetPixel based loop with direct image data access, you will get an insane speedup. Also, building a list of RECTs and then ExtCreateRegion rather than constantly CombineRgn will also give a small speedup.

But a very nice tool - I was considering writing one of my own, and found yours by accident :-)
Posted on 2004-07-16 12:21:36 by f0dder
Yeah, the whole app is kinda lame since I didn't know much about direct bitmap access back then. :(

Speeding up the routine would probably make it usable on runtime for most cases, so this tool is probably useless anyway :grin: but I'll update it if you wish :)
Posted on 2004-07-19 11:24:53 by QvasiModo
It's not lame, it's a pretty useful tool - and the slow speed isn't
too bad since it's a generation tool. Still would be nice to have the faster code :).

Yes, you can do the calculations realtime with the direct pixel access, but there's still a little overhead... so the non-runtime generation is still a nice thing.

http://www.asmcommunity.net/board/index.php?topic=18893 has some code etc for faster version :)

PS: what about releasing the code for your tool?
Posted on 2004-07-19 11:45:29 by f0dder

It's not lame, it's a pretty useful tool - and the slow speed isn't
too bad since it's a generation tool. Still would be nice to have the faster code :).

Yes, you can do the calculations realtime with the direct pixel access, but there's still a little overhead... so the non-runtime generation is still a nice thing.

http://www.asmcommunity.net/board/index.php?topic=18893 has some code etc for faster version :)

Thanks, will do then :)
PS: what about releasing the code for your tool?

Mhm, it's because of the "embarrasment factor", so to speak. ;)
I'll have to clean up the source and add some comments too before releasing it. I was coding it for myself at first, so it's really messy.
Posted on 2004-07-25 00:06:21 by QvasiModo
Version 1.01

Changes:
- It's open source now ;)
- Rewritten region generator, now it uses direct bitmap access (thanks f0dder).
- Fixed some silly memory leaks.

I didn't try building a list of RECTs instead of the region APIs yet... I want to test it first to make sure I'm not generating bigger regions that way. Supposedly the APIs optimize the regions, but I'm sure they can be beaten (take a look at the "squares" sample).

As usual, feedback is very welcome :)
Posted on 2004-08-04 13:34:33 by QvasiModo
Version 1.02

Changes:
- New feature: tolerance levels. Now color matching doesn't have to be exact.
- Now the list of rectangles is generated first, instead of combining regions (faster).
- Fixed a couple silly bugs in the UI.
- Fixed a small memory leak, hopefully the last (MemProof didn't detect any more).
Posted on 2004-08-05 16:42:46 by QvasiModo
QvasiModo: GPF (write error) after calling GetFullPathName (LoadPictureH)

WinXP Pro, SP1
Posted on 2004-08-06 05:09:23 by TBD