|
It was the biggest surprise to me when I migrated from the managed
extensions in VS2003. I knew of the syntax changes but when the first
Dispose() errors came up I had to look into it and found it changed significantly.
I like it though - it's more C++-like 
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
|
|
|
|
|
Maybe these will help:
Graphics.PageScale (property)
Graphics.Transform (property)
Graphics.RotateTransform()
Graphics.TranslateTransform()
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Hi, I am using Visual Studio 2005 C++/CLI. I am delving into some event driven programming and I can use the mouse to draw a rectangle. The rectangle is drawn as the user moves the mouse with the left button down. I am using the Graphics->DrawRectangle() method. The idea here is to DrawRectangle() over the previous rectangle with a white pen the draw the new rectangle with a black pen. What I am seeing (and it makes complete sense) is that as I move the mouse the drawing of the white rectangle "covers" some of the screen display that was already there. This doesn't seem very elegant. Is there a method that will remove the previous rectangle without disturbing the existing screen display. I don't want to paint the entire screen because my application takes about 1 second to paint the entire screen.
private: System::Void Form_MouseMove(System::Object^ sender, System::Windows::Forms::MouseEventArgs^ e)
{
if(e->Button == System::Windows::Forms::MouseButtons::Left)
{
int height = zoomRectEndPos->Y - zoomRectStartPos->Y;
int width = zoomRectEndPos->X - zoomRectStartPos->X;
zoomRectEndPos = this->MousePosition;
Graphics^ g = this->CreateGraphics();
Pen^ whitePen = gcnew Pen(Color::White, 0.5);
g->DrawRectangle(whitePen, zoomRectStartPos->X, zoomRectStartPos->Y, nPreviousWidth, nPreviousHeight);
Pen^ blackPen = gcnew Pen(Color::Black, 0.5);
g->DrawRectangle(blackPen, zoomRectStartPos->X, zoomRectStartPos->Y, width, height);
nPreviousWidth = width;
nPreviousHeight = height;
}
}
Thanks,
Buck
|
|
|
|
|
Hi Buck,
I understand the normal way (adding the rubber banding to your normal OnPaint,
and Invalidate everything) causes a lot of unnecessary repaint work.
I have not used this myself, but I did read some discussions on this topic.
I do not fully like it, but here it is:
The concept is based the ControlPaint class, which has very nice DrawReversible
methods; they allow to draw a line or frame, and to undo that by drawing it again.
So there would be no need to Invalidate the underlying stuff.
Unfortunately it paints on the entire screen, using screen coordinates, and
disregarding any windowing. Hence if your form is partly obscured by the corner
of something else, it will paint over that something else (unless you
create the logic to discover what parts of your intended window are really
visible...).
If you don't mind the lack of clipping, it should work for you; it clipping
is important (and possibly complex) I am afraid there is no easy solution.
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips:
- make Visual display line numbers: Tools/Options/TextEditor/...
- show exceptions with ToString() to see all information
- before you ask a question here, search CodeProject, then Google
|
|
|
|
|
|
Here's what I hope is an easy group of questions:
I know the VS2005 IDE plugs method definitions into the .H file of C++/CLI forms because it's build on the same generator used by C#. The question is should I expend the effort to move method bodies over to the .CPP file every time I wire up a new control event handler? Is there a drawback (other than bad C++ practice) to have all of the code in the .H file? Are methods defined in the .H file without the use of they keyword "inline" treated as "inline" anyway, or are they compiled as if they were defined in the .CPP file?
Thanks.
|
|
|
|
|
Xpnctoc wrote: without the use of they keyword "inline" treated as "inline" anyway,
For information of that type I would recommend you check out Stan Lippman's blog
Xpnctoc wrote: Is there a drawback (other than bad C++ practice)
Technically it's not C++. Since you are creating a .NET assembly the native C++ use of headers files does not apply. So the the two situations are not comparable.
|
|
|
|
|
In addition to led mike's reply, I would like to mention the following. I wouldn't mess with anything produced by the wizard because your changes can affect how the wizard updates your code. In non-wizard produced code, you may have to separate declaration from definition if you have circular dependencies. Unlike the C# and VB compilers, AFAIK, you need to create forward declarations to resolve circular dependencies.
"We make a living by what we get, we make a life by what we give." --Winston Churchill
|
|
|
|
|
I appreciate the response. I do have a fairly strong background in native C++, and I'm used to setting up my data structures so as to avoid circular references. I was just wondering if there could be any impact on performance. But, as Led Mike pointed out, it is really apples to oranges since I'm dealing with managed assemblies instead of native DLLs. So I'll just continue practicing good coding conventions in my managed and unmanaged classes, and let the forms generator do its own sloppy thing
|
|
|
|
|
However, you have to be very careful with C++/CLI. Sometimes it behaves just like C++, sometimes like C# and VB, and sometimes like none of above! For instance, derived class ctors execute before base class ctors! I guess this is normal for .NET languages but it just seems so unnatural too me.
The "For instance, derived class ctors execute before base class ctors!" comment is incorrect see my post below!
-- modified at 18:55 Wednesday 29th August, 2007
"We make a living by what we get, we make a life by what we give." --Winston Churchill
|
|
|
|
|
George L. Jackson wrote: For instance, derived class ctors execute before base class ctors!
HUH?? In what case?
I know (well, I've "heard") virtual calls in constructors (never a good idea anyway)
are handled different, but AFAIK C++ ref classes are still built from the inside out.
ref class refbase
{
public:
refbase()
{
Console::WriteLine("refbase");
}
};
ref class refsuper : public refbase
{
public:
refsuper()
{
Console::WriteLine("refsuper");
}
};
int _tmain()
{
refsuper ^super = gcnew refsuper();
Console::WriteLine("\r\n");
Console::WriteLine("Press Enter to end...");
Console::ReadLine();
return 0;
}
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Oops! You are right! I meant the derived class initialization list is executed before the base class ctor. I think I had too much filet fish today.
-- modified at 19:04 Wednesday 29th August, 2007
ref class Foo
{
public:
Foo()
{
Console::WriteLine("foo.ctor");
}
};
ref class Base
{
public:
Base()
{
Console::WriteLine("base.ctor");
}
};
ref class Derived : Base
{
Foo^ f;
public:
Derived() : f(gcnew Foo)
{
Console::WriteLine("derived.ctor");
}
};
int main(array<System::String ^> ^args)
{
Derived^ d = gcnew Derived;
return 0;
}
"We make a living by what we get, we make a life by what we give." --Winston Churchill
|
|
|
|
|
|
how to assign a tooltip to a push button in c++
plz help
dghdfghdfghdfghdgh
|
|
|
|
|
There is a thing called ToolTip class, it is well documented, and MSDN
includes an example. And CodeProject has several articles about it.
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips:
- make Visual display line numbers: Tools/Options/TextEditor/...
- show exceptions with ToString() to see all information
- before you ask a question here, search CodeProject, then Google
|
|
|
|
|
I have problem retrieving the primary key for a new row that is added to the database.
This is what I have now:
DataTable^ MyTable = myDataSet->Tables[0];
DataRow^ row = MyTable->Rows->Add();
if (row != nullptr)
{
row["item_id"] = item_id;
row["use"] = use;
row["type"] = Convert::ToInt16(type);
DataAdapter->Update(myDataSet, "tblPanel");
PanelID = Convert::ToInt64(row["ID"]);
}
now the value PanelID is always 0 for the first time this loop runs, the second time and further the information is correct and I can use the PanelID to create the relation with other tables.
What am I missing?
Stefan
|
|
|
|
|
From my experience, the primary is usually created at the database server via a trigger or stored procedure. You can send your data to be added to a store procedure which can return newly created primary key.
"We make a living by what we get, we make a life by what we give." --Winston Churchill
|
|
|
|
|
I have been looking at different site and manuals for an example but have not found one containing a stored procedure. Mostly I found some SQL way to find it but it has the same problem. Strange thing is that only the first time is not working and I can't find any missing declarations.
Stefan
|
|
|
|
|
I am at work right now and cannot provide an example of how I solved the problem. I have used both Oracle and Sql Server store procedures to obtain the primary key. However, I believe there are some tricky spots.
"We make a living by what we get, we make a life by what we give." --Winston Churchill
|
|
|
|
|
led mike's post refers to what I am talking about. I also have a different solution that uses a stored procedure but it was designed to do some extra fancy stuff that may be overkill for what you have in mind.
Geo
"We make a living by what we get, we make a life by what we give." --Winston Churchill
|
|
|
|
|
|
I checked out the site and found the things I need I think.
Just pity that microsoft provides only examples in VB and C#.
Stefan
|
|
|
|
|
Stefan Baens wrote: I checked out the site and found the things I need
I'm glad you have a solution
|
|
|
|
|
I'm currently using VisualStudio2003 (and cannot change due to the fact that other team members are using it too).
My current project uses managed code to dynamically link a .NET-DLL into my program, works so far.
The only problem is, that to compile and link this DLL I need a [dllname].netmodule file, which can only be generated with VisualStudio2005.
The file is generated by linking the dll into my project (references) and automatically used when the dll is loaded.
VC2003 does not generate this file automatically, but if it is not present, the DLL cannot be used (access violation).
Using google I found this to be a bug in VC2003 but no appropriate solution.
Is there any way to generate this file with VC2003 (compiler switch, etc.) automatically??
Thx in advance
|
|
|
|
|
Hi,
AFAIK it's currently only supported to compile a netmodule in VS2005 via command line. Currently there is no IDE support for it. Because this really bugged me I looked for another way and ended up changing a single tag in the csproj-file.
Before change:
<OutputType>Library</OutputType>
After change:
<OutputType>module</OutputType> Works perfectly for me (VS2005) but you've to check if this works in VS2003, too.
After you've done this change take care not to change the output type of this project via the IDE anymore. It will of course overwrite your hand-changed tag.
Perhaps the following links can help you, too:
http://support.microsoft.com/?scid=kb%3Ben-us%3B309805&x=9&y=11[^]
http://support.microsoft.com/kb/311416/EN-US/[^]
cheers,
mykel
OMM: "Let us be thankful we have an occupation to fill. Work hard, increase production, prevent accidents and be happy."
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
