VBDrawingLib - GDI+ Implementation

[thraka]

So I'm working on the GDI+ (System.Drawing) stuff. I was wondering though for standards, how should I handle overloading?

Do we just settle for 1 method and you just have to make sure you use your variables\objects in a manner that will fit the calls or should I do Method1 Method2 Method3 for overloading?

At this moment I have the objects
Graphics
Image

About 2% done. At this point you can load a picture file into the Image class and create the graphics object from an HWND or Image object and draw the image.

It's using the GDI+ TLB by www.cyberactivex.com/

[Kelly Ethridge]

Hello thraka,

First off, let me say that I think it's fantastic that you're doing this! I look forward to seeing it!


You struck one of the biggest problems right on the head. I prefer to keep the interface as clean as possible. I don't number methods for each overloaded signature. I look at the signatures and see how all Microsoft did was keep adding an additional argument most of the time, so I could get away with having optional parameters and force compliance with the valid combinations of parameters in the function. Sometimes I couldn't though. In those cases I would allow one additional function that was an extended version, so I'd append "Ex". I have cArray.Copy and cArray.CopyEx for example.

I would never need to go past the "Ex". I'd imagine if I did, I would think of a special name to append to the original function name.

I would also take into account classes that had function pairs, like Get/Set or Read/Write. Since I couldn't define "Write", I'd use "WriteBuffer". I didn't like the underscore "Write_". So even though I could use "Read", I'd make it "ReadBuffer" to be in sync with "WriteBuffer". I'd just use "Read" if there was no corrisponding "Write" method.

If I'm being long winded, just let me know heh.

Kelly

[Kelly Ethridge]

Hello again!

I just noticed that you named the dll VBDrawingLib. Might I make a suggestion and just use VBDrawing? The Lib part isn't on the original .NET dll and you'd get 3 more characters for class names. I used Lib because the original dll was the MSCorLib. Even with that short name I still ran out of letters for a couple classes hehe.

Anyways, just a thought!

thanks,
Kelly

[thraka]

Good point! I'll rename to VBDrawing.

Yeah I agree with your points about the overloading. The problem is a lot of power from .NET is the fact that a lot of the drawing operations change the types you can use. You can use X, Y params or a POINT or a RECTANGLE ect...

The great thing about the Point and Rectangle objects is that you can add operations to them like +, -, * etc... I guess I'll just decide on the X,Y, Optional Widht, Optional Height as the main signature and branch from there. People can just use the Point.X or Rectangle.Width etc for passing in the values

Any and all feedback is welcome. I want to try and generate more interest in this project as a whole and hopefully get some others to contribute.

Since your library is basically the System, should I just make the one static class expose a member called Drawing which contains all my static objects? (GraphicsStatic, ImageStatic etc) So then in vb only the Drawing object would be native in the library and the access point to all other parts. While yours is more at the root. You have the type POINT defined in your lib i think, which might conflict with my POINT class. Not sure

just thinking about it all...

[Kelly Ethridge]

Ok.... I just took a quick peek at Graphics.DrawLine and I see your point! Such similar signatures yet not very easily supported in VB6.

Seeing all the Point, PointF, Size, SizeF, Rectangle, RectangleF and on and on... Oh and the Integer and Float versions...... wow. So were you planning on using a Type or Class for those things? I can actually see creating several DrawLine methods to start with. You may change it later. Taking on the the MS theme, there could be a DrawLine, DrawLineP, DrawLinePF, and so on... It always evolves as a pattern emerges with different method signatures. This is all just an initail knee-jerk thought hehe.

As for the static classes. I don't think there are any conflicts. I would think you could create your StaticClasses class and define all the static class names. It's a cool idea to have a Drawing method someplace to access those static class methods through for those of us that have no idea what's there.

As for the actuall static class name, I always use the original name if all it has is static methods. I do that for the benefit of the documentation generator. I thought it might be easier for people to read the docs if the original class name was used whenever possible. If the original name was needed because the class could be instantiated by someone, then I'd use the XxxStatic for the static methods. But that is all up to you!

Oh geeze, I could go on rambling about all the little decisions I had to make hehe.

And I thank you for taking an active part with this.

Kelly

[thraka]

Yeah that is how the TLB is actually formed, using the DrawLineP and DrawLinePF etc..

I think it should just be restricted to floats (Single or Double in vb6 i cannot remember hehe) for simplicity. If someone really really wants to pass in those types, they could always wrap it in a module I guess.

The way I started to structure everything is on how I found it in your source in the first place because I wanted to make sure I mimic your way. What do you use for putting in your documentation comments? Or did you do those by hand?

The next project would be incorporating the VB6 language into the VS 2005 IDE runtime hehe j/k but it's a good idea.. Hmm or even SharpDevelop since it's open source...

[Kelly Ethridge]

Ok, it all sounds good to me ;D

As for the docs, I write the comments in a form that the doc generator can understand. I use VBDOX which is on source forge.

[thraka]

Ack!!! You know I keep looking at this code and overloading I think to myself: This sucks and it's ugly!

So there are four real structures used in i would say almost all the things in the drawing library. Point, Size, Rect, and Single Integers.

Perhaps I should just model those 4 only...
Graphics.DrawImage(Image, X, Y, Optional Width, Optional Height)
Graphics.DrawImagePoint(Image, Point, Optional Size)
Graphics.DrawImageRect(Image, Rect)

By default these take the whole image and draw it at the specified location (and size if using rect or ImagePoint with Size param) but there are also other versions in GDI+ which allow you to specify the source location\size (or rect) of the image source to draw so you dont use the whole image each time.

So maybe these would fit in:
Graphics.DrawImageSource(Image, SrcX, SrcY, SrcWidth, SrcHeight, X, Y, Optional Width, Optional Height)
Graphics.DrawImagePointSource(Image, SrcPoint, SrcSize, Point, Optional Size)
Graphics.DrawImageRectSource(Image, SrcRect, Rect)

Does that look good? I think it does and you get a lot of the main functionallity with the ability for different data types...

[thraka]

Just makes me wish more and more that VB7 (the vs2002) was VB6 with more language features and still it's own runtime. I wish some of the really good hackers out there would get on to adding more language features, as if it was possible

[Kelly Ethridge]

Wow, 30 overloads! I see your point again hehe.

I see how you're separating methods that use the whole image and those that let you use part of it. You seem to be on a good path there ;D There isn't much you can do with that many different methods.

[protonx80]

hello thraka is your library available for download - i would very much like to get it if it is.