[RESOLVED] stacking several PNG files under in a windows forms

Hi Guys,
I am doing some project in which i have to implement a spirit level
(http://en.wikipedia.org/wiki/Spirit_level)

I have prepared a png file with the spirit levell frame, and parts where liquid is are transparent (but i kept the black lines because they need to be on the top)

I also prepared the image of the air bubble.

Now i am trying to stack it all together on the form and the bubble image(pictureBox) is below the png frame(pictureBox, Image PNG, backgroundColor transparent), however it cannot be seen in the transparent parts of the frame, i can only see the background image of the panel (in which are images) there.

Is there any way to make the image visible?

I am working in VS2005 under windows forms in c++

Thanks in advance,
Smallbit

Create a private Bitmap member variable and load from file (or assign from a resource) the bottom-most png. Then use the Graphics::FromImage(Image^) static method to obtain a Graphics instance that you can use to draw on the original bitmap. I would make it a private member variable, too.
On Paint event, use the Graphics object to Draw one image over the other - the transparent areas will be blended (you can also override OnPaint(...)). Use one of the DrawImage(...) overloads. These functions also allow you to translate and/or resize the image being drawn, and you can, for example, use RotateTransform(float) to - well, apply rotations.

Make sure the images all have the same dpi resolution, since this can sometimes cause unexpected results. You can use the Bitmap::SetResolution(float, float) member function to change it, in conjunction with the DpiX and DpiY properties of the Graphics class instance.

Now, you can assign that image directly to the PictureBox and draw on that, but this could produce some flicker. (... Or maybe you can't? I seem to recall that PictureBox behaves a bit weird when it comes to that. Just use a panel if there are any problems.)
To avoid flicker, you can use this Bitmap as a back buffer, and create another one to be used on the control. After you've done all the painting, just draw the first bitmap on the other (using a second Graphics object.)
Another alternative is to use a BufferedGraphics - here's a slightly modified MSDN example:

Code:

---

// Retrieves the BufferedGraphicsContext for the
        // current application domain.
        context = BufferedGraphicsManager::Current;

        // Allocates a graphics buffer
        grafx = context->Allocate( bmpGraphics, Rectangle(0, 0, bmp->Width, bmp->Height) );

---

To draw, use grafx->Graphics, assuming that grafx is a BufferedGraphics from the MSDN example. When done, call grafx->Render(), and that's it.

Thank you for the answer,
I have resolved it in other way, but your advice about flicker issue was useful in other part i had pending to resolve :DD

Cheers

Good.
Just out of curiosity, how did you do it?
I forgot to mention that you could have also used the CreateGraphics() function to obtain a Graphics instance that would draw directly on the control.

BTW, you can mark the thread as resolved by clicking on "Thread Tools" (near the top), and than "Mark Thread Resolved".

Well, I am ashamed of the way I have chosen, it does not involve any programming tricks.
Since the bubble is always visible(note that I have the top view for the spirit level) it doesn't need to be below the frame. The only thing is that the black lines (indicators) need to be over the bubble, for this purpose I used the pictureBoxes with black background and very tiny height.

So I have the JPG with frame on the background(the bubble was removed in PS) on the panel, then PNG image of the bubble (so it will be rounded) and on top of it I have two picture boxes with black lines, then I am dynamically changing the location of the picturebox with the bubble. And it works pretty nice and smooth.

Maybe soon I will apply your hints to learn something :D

Thanks again for help

I started to look for a solution to this problem before Cthulhu did post #2 and wasn't yet finished when I read this post. In the meantime I have finished my toy project, using advice from this very post (thanks :)). And now that I have it and spent so many time making it, I insist in finally posting it here... :p

In addition to the code posted below I have attached a ZIP file containing the project and a screen shot showing how the toy app looks to this post.

These are the event handlers doing the actual work:

Code:

---

// Form1.cpp

#include "stdafx.h"

#include "Form1.h"

using namespace LayeredPNGs;

System::Void Form1::trkX_Scroll(System::Object^  sender, System::EventArgs^  e)
{
  int x = trkX->Value;
  lblX->Text = String::Format("x = {0}", x);
  ptOverlayPos.X = x;
  pbBack->Invalidate();
}

System::Void Form1::trkY_Scroll(System::Object^  sender, System::EventArgs^  e)
{
  int y = trkY->Maximum - trkY->Value;
  lblY->Text = String::Format("y = {0}", y);
  ptOverlayPos.Y = y;
  pbBack->Invalidate();
}

System::Void Form1::pbBack_Paint(System::Object^  sender, System::Windows::Forms::PaintEventArgs^  e)
{
  e->Graphics->DrawImage(bmpOverlay, ptOverlayPos);
}

---

Actually, as you can see, the picture box' Paint handler is as short as can be. :cool:

The following is the constructor that sets up the form class:

Code:

---

  public:
    Form1(void) : ptOverlayPos(0, 0)
    {
      InitializeComponent();
      //
      //TODO: Konstruktorcode hier hinzufügen.
      //

      /*

      // The following is meant to set up the Bitmap object from an image resource. Unfortunately
      // it tends to fail regularly (at least for me) due to the "vanishing resource problem".

      ComponentResourceManager ^cresm = gcnew ComponentResourceManager(Form1::typeid);
      Object ^objResource = cresm->GetObject("Overlay.png");
      Diagnostics::Trace::Assert(objResource != nullptr, "Overlay bitmap construction from resource failed");
      bmpOverlay = gcnew Bitmap(safe_cast<Drawing::Image ^>(objResource));

      */

      // This is the alternative way, constructing the Bitmap object from a disk file
      // (wouldn't really like that in a real-life app though):

      bmpOverlay = gcnew Bitmap("Overlay.png");
    }

---

Much of this code is actually commented out, but I wanted to show it because that's the real way of constructing the bitmap object.

The "vanishing resource problem" mentioned there means: Whenever I change even the tiniest bit of the form design, all resources I have added manually to Form1.resX vanish instantly. :mad: I probably would need to add a resX file to the project that's independent from the form but I have not yet managed to do this. Maybe I'm too dumb to comprehend how to use this managed resource "editor" or it's simply another weird limitation of the Express Edition. Actually, I wouldn't really like either option... :sick:

Hi Eri,

What do you mean by "vanishing resource problem" ?


Anyway, I cannot run your project (its VS2010?) but I've seen the code and screen. In the original problem I meant to display (lets say on your example) two PNG stars one over another, and I wanted them both as well as the background image to be visible all the time.

Edit: If Anybody is interested : I have uploaded screen of what I have done(post #3), the frame texture is to be replaced once I will get better pictures.
SpiritLevel.Jpg shows the initial position , and SpiritLevel2.jpg shows the bubbles in different positions.

Quote:

---

Originally Posted by smallbit

What do you mean by "vanishing resource problem" ?

---

Well, that's no technical term; I just invented it for something that has been bugging me for quite some time now. Essentially it means:

• I add a resource to Form1.resX. -> Everything is fine, compiles and runs ok an arbitrary number of times.
• I change anything in the design of Form1 (e.g. just move a control by one pixel). -> The resource I added in the step above is gone. Still compiles but loading the resource at runtime naturally fails.

Clearer now?

Quote:

---

Anyway, I cannot run your project (its VS2010?) but I've seen the code and screen. In the original problem I meant to display (lets say on your example) two PNG stars one over another, and I wanted them both as well as the background image to be visible all the time.

---

Yes, it is VS 2010. IIRC you didn't mention which version you're using (and I don't have another one anyway :o).

I understood that you wanted two use more than just two levels of layering but I wanted to simplify the problem. Once you got that working for two layers like in my sample code you can easily extend it to any number of layers.

Your screen shots look really nice, i.e. realistic. The user won't see that you cheated a bit (as I understood post #5) and in the end it's the result that matters anyway. :thumb:

Quote:

---

Originally Posted by smallbit

Edit: If Anybody is interested : I have uploaded screen of what I have done(post #3), the frame texture is to be replaced once I will get better pictures.
SpiritLevel.Jpg shows the initial position , and SpiritLevel2.jpg shows the bubbles in different positions.

---

Nice. About the implementation: it's fine - nice trick; should be OK as long as it works, without creating problems with potential future requirement changes.

Quote:

---

Originally Posted by Eri523

[...] In the meantime I have finished my toy project, using advice from this very post (thanks :)). And now that I have it and spent so many time making it, I insist in finally posting it here... :p

---

Since we're taking toy projects, here's mine :D: a good chance to address some topics started by both you and the OP.
(A pentagram... You devil.)

But first...
I'm sure some of you will say "Well, duh!" after you read this, but I wasn't aware of it until now...
There I was, setting up my VS2010 test/toy project, and all of a sudden, the status line greets me with: "IntelliSense unavailable for C++/CLI".
I found it a bit strange, and after some web research I found out that Microsoft dumped it...
Uhm...
Wait... WHAT?!
WHAT???

I mean, how insane is that? What are you guys using, some third party tool? Or you just - accept your fate?
So, back to VS2008. (Still, compared to it's C# equivalent, C++/CLI IntelliSense is relatively crappy...)

But, let me return to my toy project.
Since I code mostly in C#, I might have overlooked some C++/CLI specific intricacies, so I'd appreciate feedback if you spot any.

Anyway, the projects shows how to render transparent images, and how to apply some slightly advanced transformations to them (most of it is done in the Paint event handler). It also shows a way around Eri523's "vanishing resource problem" (more on that later).

Basically, it draws a (semi)transparent bubble on the background, and then another partially transparent image on top of that. The bubble can be moved around: clicking on the client area activates the "bubble control mode", after which you can move the bubble by simply moving the mouse. Clicking again disables this behavior.

The code contains comments, and the most important of them all start with
// INFO:
so you can search for that.

I've also created a VS2005 conversion, and included it in the attached RAR archive.

Quote:

---

Originally Posted by Eri523

Code:

---

      // The following is meant to set up the Bitmap object from an image resource. Unfortunately
      // it tends to fail regularly (at least for me) due to the "vanishing resource problem".

      ComponentResourceManager ^cresm = gcnew ComponentResourceManager(Form1::typeid);
      Object ^objResource = cresm->GetObject("Overlay.png");
      Diagnostics::Trace::Assert(objResource != nullptr, "Overlay bitmap construction from resource failed");
      bmpOverlay = gcnew Bitmap(safe_cast<Drawing::Image ^>(objResource));

      */

      // This is the alternative way, constructing the Bitmap object from a disk file
      // (wouldn't really like that in a real-life app though):

      bmpOverlay = gcnew Bitmap("Overlay.png");
    }

---

[...]

The "vanishing resource problem" mentioned there means: Whenever I change even the tiniest bit of the form design, all resources I have added manually to Form1.resX vanish instantly. :mad: I probably would need to add a resX file to the project that's independent from the form but I have not yet managed to do this. Maybe I'm too dumb to comprehend how to use this managed resource "editor" or it's simply another weird limitation of the Express Edition. Actually, I wouldn't really like either option... :sick:

---

VS can sometimes be rather weird. To avoid this problem, right-click on the "Resource Files" folder in your project tree, and then "Add" --> "New Item..." .
Add a new Assembly Resource File (.resx); in my example, I named it "Resuouces.resx".

(Should have been "Resources.resx", but I somehow misspelled it...)

The first parameter the constructor accepts is the name of the .resources file generated when the application is built (see the comment for more detail.)

Then add the following code:

Code:

---

                        // INFO: To find out what the first parameter should be, right-click
                        // Resources.resx, choose Properties, expand all, click on Command Line,
                        // copy the name of the .resources file (withouth the extension).
                        System::Resources::ResourceManager^ rmngr
                                = gcnew System::Resources::ResourceManager("TheBubbleTest.Resuouces",
                                this->GetType()->Assembly);

---

But, if you ask me: Leverage the power of .NET's support for multiple languages.
Create a new, empty C# Class Library project, and delete the Class1.cs file.
Right click on the project name, select "Add" --> "New Item...", and pick "Resources File".

Then add all of your resources using the resource designer, and finally change the "Access Modifier:" drop-down box to "Public".
The IDE automatically generates the code needed to access all of the resources. You can check out this file by expanding the {fileName}.resx node in the project tree and opening the {fileName}.Designer.cs file.
When done, simply reference the assembly from your C++/CLI project.

It's really neat - it will allow you to initialize your variables using auto-generated properties, like this:

Bitmap^ bmp = Resources::MyImage;

Quote:

---

Code:

---

// This is the alternative way, constructing the Bitmap object from a disk file
// (wouldn't really like that in a real-life app though):
bmpOverlay = gcnew Bitmap("Overlay.png");

---

---

Well, that depends on the type of the app - what if whatever needs to be drawn also needs to be configurable? (Skins, game characteres, stuff like that...)

As for the drawing logic - here's a simple way to create a BufferedGraphics object:

Code:

---

m_buffG = BufferedGraphicsManager::Current->Allocate(CreateGraphics(), ClientRectangle);

---

If drawing directly on the form, this is also important:

Code:

---

// INFO: Make sure to set the ControlStyles::Opaque flag
this->SetStyle(ControlStyles::Opaque | ControlStyles::AllPaintingInWmPaint, true);

---

(I sometimes like to use "this" ptr to increase readability and clarity.)

The final point I'd like to make is: although I used a Paint event handler, in situations like this, I would generally prefer to override OnPaint().

Quote:

---

Originally Posted by TheGreatCthulhu

[...] It also shows a way around Eri523's "vanishing resource problem" (more on that later).

[...]

VS can sometimes be rather weird. To avoid this problem, right-click on the "Resource Files" folder in your project tree, and then "Add" --> "New Item..." .
Add a new Assembly Resource File (.resx) [...].

---

When I originally read that I though that it'd now be on me to be stumped (like you with the missing Intellisense in VS 2010, but with the opposite sign). In that case it would really have been me who was too dumb to operate this aspect of VS.

Too bad this doesn't work either on my VS 2010 Express. :cry: I had always tried to add the .resx file using the Add New Item button from the tool bar and the dialog that opens when I click it simply doesn't offer the option to add a .resx file. I would have been really surprised if the context menu item would behave differently, and in fact it doesn't.

Your project compiles and run without problems on my 2010 though (after the automatic conversion). (BTW, I really like it! :cool:) In particular it looked as if the managed resource editor would accept the pre-existing .resx file in my first brief test. This makes me wonder if it could help if someone gave me an empty .resx file that I could simply copy into my projects and then add it as an existing item...

I shouldn't really stay up as long as usual tonight, as I have a major family celebration tomorrow and it starts really early for my habits. I'll write a more comprehensive response to your post tomorrow.

Quote:

---

Originally Posted by Eri523

This makes me wonder if it could help if someone gave me an empty .resx file that I could simply copy into my projects and then add it as an existing item...

---

You already have one: just copy Form1.resX and rename it, then add as an existing item. It should work.

Quote:

---

Originally Posted by TheGreatCthulhu

You already have one: just copy Form1.resX and rename it, then add as an existing item. It should work.

---

Now this finally seems to do the trick! :D At least it survives form design changes (but why shouldn't it?) and I also tested a Rebuild All. Too bad I can't rate you yet again... :thumb: (It also reveals one of my worst habits: often thinking way too complicated... :rolleyes:)

My code that constructs the overlay bitmap object now looks like this:

Code:

---

      // Option #3, according to what TheGreatCthulhu described in
      // http://www.codeguru.com/forum/showthread.php?p=2004364:

      ResourceManager ^resm = gcnew ResourceManager("LayeredPNGs.Resources", Form1::typeid->Assembly);
      Object ^objResource = resm->GetObject("Overlay.png");
      Diagnostics::Trace::Assert(objResource != nullptr, "Overlay bitmap construction from resource failed");
      bmpOverlay = safe_cast<Bitmap ^>(objResource);

---

Quote:

---

Originally Posted by TheGreatCthulhu

(A pentagram... You devil.)

---

:cool:

Quote:

---

But first...
I'm sure some of you will say "Well, duh!" after you read this, but I wasn't aware of it until now...
There I was, setting up my VS2010 test/toy project, and all of a sudden, the status line greets me with: "IntelliSense unavailable for C++/CLI".
I found it a bit strange, and after some web research I found out that Microsoft dumped it...
Uhm...
Wait... WHAT?!
WHAT???

I mean, how insane is that? What are you guys using, some third party tool? Or you just - accept your fate?

---

Well, the last VC++ version I used before this one was 6 and it had no Intellisense at all. So I don't miss it as much as others obviously do. (Yes, in that respect I just accept my fate.) OTOH I really appreciate it when writing native C++ programs. So yes, of course it would be nice to have it for C++/CLI too.

As a little consolation: Even in C++/CLI you have Intellisense when typing header names in an #include... :rolleyes:

Quote:

---

So, back to VS2008. (Still, compared to it's C# equivalent, C++/CLI IntelliSense is relatively crappy...)

---

Now that surprises me a bit. I always thought C++/CLI never had Intellisense. But if they actually already had it in earlier versions, why not at least keep it if they don't want to improve it? :confused:

I once asked here on CG if it might be that MS simply doesn't want developers to use C++/CLI. I got no answer that I felt comfortable with and finally had to conclude: Yes, it actually looks as if they don't want us to use it. :(

Quote:

---

But, let me return to my toy project.
Since I code mostly in C#, I might have overlooked some C++/CLI specific intricacies, so I'd appreciate feedback if you spot any.

---

No, I didn't see anything in your code that really looked somehow "un-C++/CLI-ish" to me. I would probably have written some details differently but I think that's just a matter of personal style.

Actually, I myself never had a closer look at the SetStyle() method because it's protected and I usually try to avoid using classes I derived from controls because I didn't yet find a way to have the Forms Designer cooperate with them. I simply missed the fact that the form usually is a derived class already and so I can easily use it. It looks as if it opens up some nice low-level opportunities. :)

Ah, and I usually prefer Form1::typeid over this->GetType(). They are effectively very similar, with two main differences: The former is evaluated at compile time and therefore slightly more efficient. (Ok, that's probably no issue in most situations anyway.) Also, the former is not literally portable between diferent classes because it explicitly specifies the class name. IMO essentially another one of these matter-of-taste things.

Quote:

---

But, if you ask me: Leverage the power of .NET's support for multiple languages.

[...]

---

Unfortunately the Express Editions don't support multi-language projects. Or could this be done as well in two separate projects in the two separate C++/CLI and C# Express Editions?

To me it looks as if this generates a resource-only assembly. But can that then be linked statically? This is what I'd usually prefer (see below).

Quote:

---

Well, that depends on the type of the app - what if whatever needs to be drawn also needs to be configurable? (Skins, game characteres, stuff like that...)

---

Right, that really depends. What you describe looks like a bigger app than those I am usually writing at the time. I try to create these apps as monolithic .exes if possible to simplify deployment and "installation". But once the app grows beyond a certain point this isn't that easy anymore anyway.

Particularly in the scenario you describe it also depends on whether you really want to allow your users to configure things like that (bitmaps in this example) without your app being able to enforce constraints like size or bit-depth of the images while the actual configuration process is happening.

Quote:

---

As for the drawing logic - here's a simple way to create a BufferedGraphics object:

Code:

---

m_buffG = BufferedGraphicsManager::Current->Allocate(CreateGraphics(), ClientRectangle);

---

If drawing directly on the form, this is also important:

[...]

---

As you probably have seen I'm not drawing directly to the form but instead to the background image picture box. Is that the reason why I didn't encounter problems of that kind or have I just been lucky?

Quote:

---

The final point I'd like to make is: although I used a Paint event handler, in situations like this, I would generally prefer to override OnPaint().

---

As explained above I have exactly the opposite preference. This is likely to change however once I find a way to have the Forms Designer cooperate with my derived control classes without having to go through too much hassle because deriving allows better encapsulation.

Quote:

---

Originally Posted by Eri523

Well, the last VC++ version I used before this one was 6 and it had no Intellisense at all. So I don't miss it as much as others obviously do. (Yes, in that respect I just accept my fate.) OTOH I really appreciate it when writing native C++ programs. So yes, of course it would be nice to have it for C++/CLI too.

As a little consolation: Even in C++/CLI you have Intellisense when typing header names in an #include... :rolleyes:

[...]

Now that surprises me a bit. I always thought C++/CLI never had Intellisense. But if they actually already had it in earlier versions, why not at least keep it if they don't want to improve it? :confused:

I once asked here on CG if it might be that MS simply doesn't want developers to use C++/CLI. I got no answer that I felt comfortable with and finally had to conclude: Yes, it actually looks as if they don't want us to use it. :(

---

VS 2005 and VS 2008 had it (as well as VS.NET, I think), but it was a bit sluggish at times. And suddenly they've decided to drop it in VS 2010; from what I've read, it was supposed to be provided with a service pack, but then they announced that it will not appear until the next version comes out. On top of that - the resources problem that you described, and similar issues. (A new C# Win Forms project includes a separate .resx file as well as other supporting code files.)

Personally, I believe that Microsoft is having some problems with the C++/CLI team or something. I feel that they could have provided a better support for the language (starting with the VS itself) - especially because they deemed it "the most powerful .NET language".

Quote:

---

Originally Posted by Eri523

No, I didn't see anything in your code that really looked somehow "un-C++/CLI-ish" to me. I would probably have written some details differently but I think that's just a matter of personal style.

---

What I was a bit concerned about was: I'm not sure is there a difference between safe_cast<Type>(var) and (Type)var, and if there is, is it context-dependent (managed/native), and when should one be preferred over the other.

Quote:

---

Originally Posted by Eri523

Unfortunately the Express Editions don't support multi-language projects. Or could this be done as well in two separate projects in the two separate C++/CLI and C# Express Editions?

To me it looks as if this generates a resource-only assembly. But can that then be linked statically? This is what I'd usually prefer (see below).

---

Well yes: I suggested that as an alternative, if it turns out that there's no other way (but now there is - you can copy the .resx file), and also because the VS C# IDE would generate a handy interface (and implementation) for easy access. It can be done with two separate .NET projects; when I was talking about the support for multiple languages, I was thinking of the support inherent to .NET framework itself, not to VS specifically. Generally speaking, you can have components written in different .NET languages working together with no trouble most of times - it all gets compiled to MSIL.

Now that you mention it, I'm not sure if it can be statically linked, but there probably is a way, although I suspect that it would involve adding the dll as a file resource, and then manually loading the assembly, or something along those lines. Maybe I'm wrong. (My turn to think in a too complicated way...)

Quote:

---

Originally Posted by Eri523

As you probably have seen I'm not drawing directly to the form but instead to the background image picture box. Is that the reason why I didn't encounter problems of that kind or have I just been lucky?

---

When I said "If drawing directly on the form, this is also important:", i wasn't referring to BufferedGraphics, but to the code directly bellow that sentence, where the Opaque style was set. In my application, there's basically a constant loop, formed by calling Invalidate() at the end of the Paint event handler. So the application constantly redraws itself - a similar system is used by games, and in another way, by the native windows in the form of a message loop. In such a setting, where there's constant repainting at relatively high rates, a lot of flickering is bound to happen unless a BufferedGraphics is used and the Opaque style is set. (There's also an OptimizedDoubleBuffer style, but that won't work.)
My guess is that your app didn't exhibit significant flickering problems because it's only updated when the sliders are moved, and/or maybe because you're drawing only one image.

BufferedGraphics (and double buffering) is really beneficial only if there are several drawing passes on the same surface, like when you have to create a composite of several images (which is what the OP wanted), and perhaps to reduce tearing on a larger area.

Quote:

---

Originally Posted by Eri523

As explained above I have exactly the opposite preference. This is likely to change however once I find a way to have the orms Designer cooperate with my derived control classes without having to go through too much hassle because deriving allows better encapsulation.

---

I don't think that the event-based approach violates encapsulation. Generally, I'd prefer using events, too; but in the context of my sample app, performance is somewhat critical, and thus an event handler is just another unnecessary level of indirection. (But, it's a small app, so I figured I could get away with it.)

EDIT: Oh, I forgot to mention that the designer should be able to cooperate with user-defined controls, and that you can also specify which designer using the Designer attribute. (Also, see this.)

Quote:

---

Originally Posted by TheGreatCthulhu

[...] On top of that - the resources problem that you described, and similar issues. [...]

---

I hope for the users of the Pro Edition that this resources problem is specific to the Express Edition. To clarify: MS may actually argue that there is some point in dumping "foreign" resources in a form-specific .resx file upon form design changes but I hope there's a less hackish way to add independent .resx files to projects in the Pro Edition. As I understood your post, there is.

Quote:

---

Personally, I believe that Microsoft is having some problems with the C++/CLI team or something. I feel that they could have provided a better support for the language (starting with the VS itself) - especially because they deemed it "the most powerful .NET language".

---

That thing about "the most powerful .NET language" is yet another surprise to me. Most if not all of the celebrities around here seem to agree that C++/CLI is only really useful for managed/native interop. It looks like they prefer to only write wrappers in C++/CLI and implement the two ends of "the real thing" in native C++ and C# (or any other .NET language but that seems to be less preferred). You certainly have seen that I have a different opinion, but that clearly makes me part of a minority. (Maybe I just have found a fellow renegade? :cool:)

Quote:

---

What I was a bit concerned about was: I'm not sure is there a difference between safe_cast<Type>(var) and (Type)var, and if there is, is it context-dependent (managed/native), and when should one be preferred over the other.

---

I always have found casting in C++ confusing (have done many years of C before) and C++/CLI makes it even worse. My particular concern is that, as I understand it, the C-style cast may behave like a safe_cast, static_cast or even reinterpret_cast depending on some context of which I don't know what it is. :confused:

It looks tempting to simply always use dynamic_cast in C++/CLI and it actually has never failed for me unless I fed it a really incompatible type, but of course this is expensive.

I have found (and immideately bookmarked) an MSDN root page about casting operators but haven't yet thorougly studied the pages that the links lead to. You may already know this page; it's not really hidden...

Quote:

---

Now that you mention it, I'm not sure if it can be statically linked, but there probably is a way, although I suspect that it would involve adding the dll as a file resource, and then manually loading the assembly, or something along those lines. Maybe I'm wrong. (My turn to think in a too complicated way...)

---

Yes, that looks really complicated. As long as it's possible I'd prefer "real" embedded resources in the assembly they belong to.

Quote:

---

I don't think that the event-based approach violates encapsulation. Generally, I'd prefer using events, too; but in the context of my sample app, performance is somewhat critical, and thus an event handler is just another unnecessary level of indirection. (But, it's a small app, so I figured I could get away with it.)

---

Well, I don't consider the event-based approach evil but to be honest it doesn't adhere to the pure doctrine: Events pertaining to a certain class should be handled by members of that class. But in real life things often look different: In (resp. for) the PentagramBox class I wrote for another thread (but didn't post because this was a homework assignment) that already was derived from a control class I actually used a combination of both approaches (where the base member override approach dominated, however).

Quote:

---

Originally Posted by Eri523

I hope for the users of the Pro Edition that this resources problem is specific to the Express Edition. To clarify: MS may actually argue that there is some point in dumping "foreign" resources in a form-specific .resx file upon form design changes but I hope there's a less hackish way to add independent .resx files to projects in the Pro Edition. As I understood your post, there is.

---

Yeah - but note this: when you create a C# Windows Forms project, you get a separate resource file included, as well as all the supporting functionality I described. The form-related resource file is still there, but it's not normally used, nor there's a need for it to be used. It's collapsed under the form node in the project tree, so you barely even notice it - I guess it's reserved for the designer (I think that the IDE might use it when you work with some specific controls.)
Anyway, all the resources are normally stored in this separate file.
It's really strange that a C++/CLI project doesn't include it, and even stranger that the Express Edition doesn't provide a way to include it.
:confused:

Quote:

---

That thing about "the most powerful .NET language" is yet another surprise to me.

---

http://msdn.microsoft.com/en-us/libr...=vs.80%29.aspx

Quote:

---

Most if not all of the celebrities around here seem to agree that C++/CLI is only really useful for managed/native interop. It looks like they prefer to only write wrappers in C++/CLI and implement the two ends of "the real thing" in native C++ and C# (or any other .NET language but that seems to be less preferred). You certainly have seen that I have a different opinion, but that clearly makes me part of a minority. (Maybe I just have found a fellow renegade? :cool:)

---

Well, power is one thing, and usefulness is another - but I'm not saying C++/CLI is not useful. But it surely is a powerful language - it provides C++ interop along with PInvoke, it can do some stuff you can't do with other .NET languages, and it provides a lower level access to the framework. If it's usefulness is limited, we have Microsoft to blame: generally, the support could be better, and especially so when it comes to the IDE.
With C#, you can choose from a bunch of different types projects: Windows Forms, WPF, Silverligt, WCF, WF, Web..., while C++/CLI only comes with Console App, and Windows Forms -based projects.

For example, you could probably create a WPF application using C++/CLI, but it would be cumbersome to code it without the support of the IDE. (bunch of stuff that needs to be set up, and XAML, all manually.)

As for me, I'm all for C# :D - it's not perfect (nothing is), but it's simply beautiful, so elegant and well thought of.
But, I've had the chance to read the remarks of native C++ developers about C# and .NET in general being to slow too do this, or too slow to do that, or similar.
As it turns out, some of them simply have a prejudice about the .NET framework, based on their lack of understanding. I couldn't resist to comment on such statements on a few occasions, so in that sense, I'm a bit of a renegade myself.

Quote:

---

I have found (and immideately bookmarked) an MSDN root page about casting operators

---

Hm... After some digging, the docs say that C-style casts should be avoided in CLR projects.

Quote:

---

Well, I don't consider the event-based approach evil but to be honest it doesn't adhere to the pure doctrine: Events pertaining to a certain class should be handled by members of that class. But in real life things often look different: In (resp. for) the PentagramBox class I wrote for another thread (but didn't post because this was a homework assignment) that already was derived from a control class I actually used a combination of both approches (where the base member override approach dominated, however).

---

But, .NET events are essentially just a syntactic sugar for what is in its core the Observer pattern. Events are a form of the public interface, so in that sense, handling an event is no different from calling public methods or using public properties. It can break encapsulation in the same way a method can (by directly exposing some internal aspect of the class). Semantically, events are meant to provide a notification when some state changes, so that event clients (observers) might respond to them.

For example, a button usually does not handle its own Click event, but some other, external class. The class that fires the events "knows" when the internal state changes, since (if the encapsulation principle was respected) it is the one that changes the state. In that sense, there's generally no need for a class to handle its own events, unless they come from a parent class, and no other mechanism exist.
Just as sometimes a method can break encapsulation by exposing a pointer or a .NET handle of an internal object, so that an external class might alter it's state, so can an event.
Sometimes, this behavior is desirable, sometimes it's not.

In part, it's a matter of preference, and in part is driven by the requirements.