Managed C++/CLI

Re: cannot convert parameter 1 from 'cli::array ^' to 'cli::array ^'

7-Aug-07 14:22

Hi Buck,

I think you are looking at the wrong line.

BTW: I suggest you make Visual display line numbers (see my sig), then look at the
details of the compiler's error messages.

failed_die->Copy is not OK, Copy is a static method in the Array class;
as opposed to CopyTo which is an instance method.

Furthermore:

do you really need to copy the array ? an array is an object, so you can store
its reference as often as you want; it will get garbage collected only after all
references to it become unreachable.

So the only way I see to copy an array would be if you need two arrays that initially
contain the same data, but then go live their separate lives, and may be modified
independently from one another.

Smile | :)

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

BuckBrown8-Aug-07 5:37

Re: cannot convert parameter 1 from 'cli::array ^' to 'cli::array ^'

8-Aug-07 5:37

Thanks, I have been thinking of the gc from a scope point of view, that when the function returned the gc would do it's thing and my FailMap reference would be lost. Side note: I think I had this same compiler error message the first time I tried to use CLI arrays. The problem then had to do with name spaces.

Buck

BuckBrown8-Aug-07 7:22

Re: cannot convert parameter 1 from 'cli::array ^' to 'cli::array ^'

8-Aug-07 7:22

Boy, this painting thing is really more trouble than its worth. The only way I can get my information to display is to open the file and then open a dialog box and drag it around the screen.

Buck

Luc Pattyn8-Aug-07 7:35

Re: cannot convert parameter 1 from 'cli::array ^' to 'cli::array ^'

8-Aug-07 7:35

Hi Buck,

using a dialog box as an eraser ?
seems you forgot to call Invalidate() when your data has changed in such a way
that a (re)paint is necessary.
We discussed that a while back on some other thread...

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles]

BuckBrown8-Aug-07 11:45

Re: cannot convert parameter 1 from 'cli::array ^' to 'cli::array ^'

8-Aug-07 11:45

Hi Luc,

Well I finally got this structured better in that I have a single OnPaint() function that calls the DisplayWaferMap() function and I am using Invalidate(myRegion) to repaint when necessary. It took me awhile to figure out 'myRegion = gcnew Drawing::Region(Screen::PrimaryScreen->Bounds);' to set the drawing region to the screen size. The downside to all of this is that the behavior of the application is unchanged.

Luc Pattyn8-Aug-07 12:00

Re: cannot convert parameter 1 from 'cli::array ^' to 'cli::array ^'

8-Aug-07 12:00

Hi Buck,

1.
there is no need to specify a region to Invalidate(); if anything, its purpose is to
partially invalidate, i.e. cause a partial repaint. Setting it to the entire screen
does not make much sense, you could just leave the argument out then.

2.
No improvement?
I am pretty sure it now repaints automatically when things get covered then uncovered,
or minimized then restored; something your original code did not. That's why you had
to move the code from your menu item handler to the paint handler.
(And later you will appreciate if you would want to print !)

3.
So I guess your remaining worries are with speed. Maybe best thing to do is you show
the current paint code, give some context and speed estimates, so we can all have a look.

Greetings

Luc Pattyn [Forum Guidelines] [My Articles]

BuckBrown9-Aug-07 9:23

Re: cannot convert parameter 1 from 'cli::array ^' to 'cli::array ^'

9-Aug-07 9:23

Hi Luc, Everything Microsoft always seems to work the opposite of what you would expect.

1. The reason that I needed to specify a region (the entire screen) for invalidate is because without specifying the entire screen as a region the entire screen would be erased and only the area under the last control is painted. I tried using Update() since it says that its purpose is to redraw anything disturbed by the control but it did nothing.

2. Not in the time it takes to paint the array. If I remark out the function call that draws the array then everything is lightning quick. But if I dont and I bring up a dialog box of any size, when I try to move the dialog box it actually changes position about once a second (the time it takes to paint the array) wheather or not I have any graphics covered by the dialog box or not. And yes I am now delving into printing. The command seemokay enough but I can't figure out how to get my screen info into a document to print. I will be posting on this issue since I have found very little on code project or by googling for half a day.

3. The speed isn't that big of an issue for me, more curiosity as to why this is such a dog compared to MFC. I can send you a copy of the code if you email me where to send it. Side note: I have not received an email when my posts are replied to even though I have the box checked and just received an email confirmation from code project, so I don't know why answers to my posts do not email me.

I'm at brown@toko.com

Buck

Luc Pattyn9-Aug-07 10:09

Re: cannot convert parameter 1 from 'cli::array ^' to 'cli::array ^' [modified]

9-Aug-07 10:09

Hi Buck,

1.
I will look into this, it sounds a mystery to me. I have never needed Update() at all,
and most often I don't specify a repaint rectangle or region.

2.
Seems like something still is not organized correctly. I look into that too.
Yes, printing on Windows is very strange at first; once you got it right for one app,
it becomes simple except for one aspect: predicting how many pages a document would take.
We can discuss this further, preferably after I had a chance to look into the other issues,
I would not want to add/modify printing code when the rest is still a bit shaky.

3.
Speed, even if not an issue, is getting my attention anyhow. Whatever the code, I want to
understand why it runs at the speed it runs, at what can be done to improve it.

I've sent you my coordinates, so we'll be in touch I guess.

Greetings

Luc Pattyn [Forum Guidelines] [My Articles]

George L. Jackson7-Aug-07 15:05

George L. Jackson

7-Aug-07 15:05

In addition to the above reply, value struct Die of array<Die>^ Failed and value struct Die of array<Die>^ FailedDie may look exactly the same but, in fact, are not. They are defined in different scopes. You need to define value struct Die only in one place!

-- modified at 6:01 Wednesday 8th August, 2007

"We make a living by what we get, we make a life by what we give." --Winston Churchill

Entry point of exe

Nandu_77b7-Aug-07 2:09

7-Aug-07 2:09

Hi,

what is an entry point of an EXE file, which is built from various compailer, like turob c++, VS 6.0 and VS 2005.??

Thanks in Advance.

Re: Entry point of exe

Luc Pattyn7-Aug-07 2:42

7-Aug-07 2:42

The entry point is where the execution of your program begins. In C it would be the start of
the main() function, in C# the static Main() method, etc. It basically is the value
your CPU's program counter needs to be initialized to once your program got loaded
into memory.

Luc Pattyn [Forum Guidelines] [My Articles]

this weeks tips:
- make Visual display line numbers: Tools/Options/TextEditor/AllLanguages/General
- show exceptions with ToString() to see all information
- before you ask a question here, search CodeProject, then Google

Re: Entry point of exe

Nandu_77b9-Aug-07 4:52

Diff between array and list.

9-Aug-07 4:52

Can any one share the idea, what actualy going inside main() funcation.

Nandu_77b7-Aug-07 0:47

Re: Diff between array and list.

7-Aug-07 0:47

Hi,

1)What is the difference between a list and array?
2)Which one to use and when?
3)Which one is the best one to use (array or list), when we have a 100 data elements of int type?

Thanks
Maha

Luc Pattyn7-Aug-07 1:39

Re: Diff between array and list.

7-Aug-07 1:39

The best one does not depend on the type of elements you are holding, it depends
on the kind of operations you want to perform most often:

- they are equally good at enumerating or traversing the collection
- arrays are better at referencing by index (do not need finding sequentially)
- lists are better at inserting, removing (do not need copying)

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles]

Nandu_77b9-Aug-07 4:51

minimizing dialog to system tray

9-Aug-07 4:51

Thank You

dona jain6-Aug-07 18:50

dona jain

6-Aug-07 18:50

i succeeded in making tray icon..bur how to minimize it to tray only when i click on minimize button.also after filling all three field which are asked and then when i press ok i want the dialog window to minimize to taskbar icon..please help me...my code is as follows:

#include <windows.h>
#include "resource.h"
#include <cstdlib>
#include<atlstr.h>
#include <fstream>
#include<iostream>
#include<string.h>
#include "FileOperation.h"
#include<stdio.h>
#define WM_ICON_NOTIFY WM_USER+1

//---------------------------------------------------------------------------
LPSTR lpString;
HWND hWnd;

LRESULT CALLBACK DlgProc(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam);
//---------------------------------------------------------------------------
INT WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,LPSTR lpCmdLine, int nCmdShow)
{
DialogBox(hInstance, MAKEINTRESOURCE(IDD_DLGFIRST),hWnd, reinterpret_cast<dlgproc>(DlgProc));
return FALSE;
}

//---------------------------------------------------------------------------
LRESULT CALLBACK DlgProc(HWND hWndDlg, UINT Msg, WPARAM wParam, LPARAM lParam)
{

char cPath[20];
char cUserName[20];
char cPassword[20];
switch(Msg)
{

case WM_INITDIALOG:
{
}

case WM_ICON_NOTIFY:
{
}
case WM_LBUTTONDBLCLK:
{
ShowWindow(hWndDlg, IDD_DLGFIRST);
break;
}

break;

case WM_COMMAND:
{

switch(wParam)
{

case IDOK:
{
size_t nLen;
GetDlgItemText(hWndDlg, IDC_EDIT1, cPath, 20);
nLen = strlen(cPath);
if (nLen == 0)
{
MessageBox(hWndDlg,"Please Enter SVN Path","Error",MB_ICONERROR);
break;
}
GetDlgItemText(hWndDlg, IDC_EDIT2, cUserName, 20);
nLen = strlen(cUserName);
if (nLen == 0)
{
MessageBox(hWndDlg,"Please Enter your user name","Error",MB_ICONERROR);
break;
}
GetDlgItemText(hWndDlg, IDC_EDIT3, cPassword, 20);
nLen = strlen(cPassword);
if (nLen == 0)
{
MessageBox(hWndDlg,"Please Enter your Password ","Error",MB_ICONERROR);
break;
}
/*EndDialog(hWndDlg, 0);*/

/*std::ofstream file ("config.txt");
file << " SVN Path entered by user is -> "<<cpath <<="" std::endl;
file="" "="" svn="" user="" name="" entered="" by="" -="">" <<cusername <<="" std::endl;
file="" "="" svn="" password="" entered="" by="" user="" -="">"<

Re: minimizing dialog to system tray

Mark Salsbery6-Aug-07 20:12

Mark Salsbery

6-Aug-07 20:12

Still haven't found the right discussion board?

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Re: minimizing dialog to system tray

iddqd5157-Aug-07 3:27

iddqd515

7-Aug-07 3:27

but reading is so hard Frown | :(

Repainting Display Seems Slow

BuckBrown6-Aug-07 11:03

6-Aug-07 11:03

Hi, I am using Visual Studio 2005 C++/CLI. I have an application that draws the contents of a 200 by 200 two-dimensional array. I also need to redraw the screen when I change the orientation of the display. In Visual C++ MFC updates to the display seemed almost instantaneous (entire display repainted in the blink of an eye. But the way I am doing it now you can see the screen paint from top to bottom in about a second. Seems way slow to the way it was before. Is the C++/CLI GDI+ that much slower than before? Also, if I pull up a dialog box that covers part of my display and then close it, the part of the display that was covered appears blank. Is there a command that will repaint that part of the display without having to redraw the entire display?

Thanks

Buck

Luc Pattyn6-Aug-07 11:10

6-Aug-07 11:10

Hi,

are you saying you have 200*200 controls ? if so, was that fast in C++ MFC ??

if you did your own Paint handler, seems like you should show the code.

Are you creating lots of objects while painting ?
Are you forgetting to dispose of objects that need being disposed of ?

No, the repaint when uncovered should be automatic; it will not be if it's about
some lines, images, text that you draw yourself in the wrong way (that is outside
the Paint handler).

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles]

BuckBrown6-Aug-07 11:52

6-Aug-07 11:52

It is a 200 x 200 array of structs. It is very fast in C++ MFC. No, I'm not creating a lot of objects while painting. Since the document does not repaint when the dialog box goes away I must be doing this outside the Paint handler. When I start my application I have the initial Form1.h file that I use to open a file that contains information to display. This stripped down code that creates a graphics object is shown below... Should I be doing this another way? I really don't understand "outside the Paint handler". How do I do this "inside the Paint handler"?

CWafer^ Wafer;
Graphics^ graphics;
BinDialog^ binDialog;
System::Drawing::Font^ drawFont;

private: System::Void openToolStripMenuItem_Click(System::Object^ sender, System::EventArgs^ e)
{
BinData = gcnew array<bool>(33);
BinData->Clear(BinData, 0, BinData->Length);
graphics = this->CreateGraphics();
Wafer = gcnew CWafer();
binDialog = gcnew BinDialog();
drawFont = gcnew System::Drawing::Font("Courier New", 6);
DisplayWaferMap();
viewToolStripMenuItem->Enabled::set(true);
zoomToolStripMenuItem->Enabled::set(true);
toolsToolStripMenuItem->Enabled::set(true);
printToolStripMenuItem->Enabled::set(true);
printPreviewToolStripMenuItem->Enabled::set(true);
}

//---------------------------------------------------------------------------

private: System::Void DisplayWaferMap()
{
graphics->Clear(Color::White);
DisplayMapPerimeter();
DisplayMapText();
}

//---------------------------------------------------------------------------

private: System::Void DisplayMapPerimeter()
{
Pen^ blackPen = gcnew Pen(Color::Black);
Point point1;
Point point2;
double height;
double radius;
double radians;
float start_angle;
float sweep_angle;
float angle_of_incidence = 20; // In degrees

sweep_angle = 360 - (2 * angle_of_incidence);
radians = angle_of_incidence / 57.29578;
height = this->Size.Height - 100;
radius = height / 2;

Rectangle rect = Rectangle(50, 50, (int)height, (int)height);

switch (Wafer->FlatOrientation)
{
case FLAT_RIGHT:
start_angle = angle_of_incidence;
point1.X = (int)(radius + (Math::Cos(radians) * radius) + 50);
point2.X = (int)(radius + (Math::Cos(radians) * radius) + 50);
point1.Y = (int)(radius + (Math::Sin(radians) * radius) + 50);
point2.Y = (int)(radius - (Math::Sin(radians) * radius) + 50);
break;
case FLAT_DOWN:
start_angle = angle_of_incidence + 90;
point1.X = (int)(radius - (Math::Sin(radians) * radius) + 50);
point2.X = (int)(radius + (Math::Sin(radians) * radius) + 50);
point1.Y = (int)(radius + (Math::Cos(radians) * radius) + 50);
point2.Y = (int)(radius + (Math::Cos(radians) * radius) + 50);
break;
case FLAT_LEFT:
start_angle = angle_of_incidence + 180;
point1.X = (int)(radius - (Math::Cos(radians) * radius) + 50);
point2.X = (int)(radius - (Math::Cos(radians) * radius) + 50);
point1.Y = (int)(radius + (Math::Sin(radians) * radius) + 50);
point2.Y = (int)(radius - (Math::Sin(radians) * radius) + 50);
break;
case FLAT_UP:
start_angle = angle_of_incidence + 270;
point1.X = (int)(radius - (Math::Sin(radians) * radius) + 50);
point2.X = (int)(radius + (Math::Sin(radians) * radius) + 50);
point1.Y = (int)(radius - (Math::Cos(radians) * radius) + 50);
point2.Y = (int)(radius - (Math::Cos(radians) * radius) + 50);
break;
default: break;
}
graphics->DrawArc(blackPen, rect, start_angle, sweep_angle);
graphics->DrawLine(blackPen, point1.X, point1.Y, point2.X, point2.Y);
}

//---------------------------------------------------------------------------

private: System::Void DisplayMapText()
{
System::Drawing::Font^ drawFont = gcnew System::Drawing::Font("Ariel", 14);
SolidBrush^ blackBrush = gcnew SolidBrush(Color::Black);

float x_coord;
float y_coord;
float height;
float width;

height = (float)this->Size.Height;
width = (float)this->Size.Height;

x_coord = width - 50;
y_coord = height - 250;

graphics->DrawString( "Part Number", drawFont, blackBrush, x_coord, y_coord);
graphics->DrawString( ":", drawFont, blackBrush, x_coord + 150, y_coord);
graphics->DrawString( Wafer->DeviceName, drawFont, blackBrush, x_coord + 180, y_coord);

y_coord = height - 225;
graphics->DrawString( "Lot Number", drawFont, blackBrush, x_coord, y_coord);
graphics->DrawString( ":", drawFont, blackBrush, x_coord + 150, y_coord);
graphics->DrawString( Wafer->LotNumber, drawFont, blackBrush, x_coord + 180, y_coord);

y_coord = height - 200;
graphics->DrawString( "Wafer Number", drawFont, blackBrush, x_coord, y_coord);
graphics->DrawString( ":", drawFont, blackBrush, x_coord + 150, y_coord);
graphics->DrawString( Wafer->WaferNumber, drawFont, blackBrush, x_coord + 180, y_coord);

y_coord = height - 175;
graphics->DrawString( "Yield", drawFont, blackBrush, x_coord, y_coord);
graphics->DrawString( ":", drawFont, blackBrush, x_coord + 150, y_coord);
graphics->DrawString( "100%", drawFont, blackBrush, x_coord + 180, y_coord);
}

Buck

Luc Pattyn6-Aug-07 12:14

6-Aug-07 12:14

OK, the situation is clear, the remedy takes two parts:

SPEED

Math::Sin and Math::Cos are expensive methods.
And there is a lot of subexpressions like (Math::Cos(radians) * radius) + 50);
these get evaluated over and over, don't rely on the compiler to optimize them all
away but one or two of them. Instead calculate them yourself and store the result in
a local variable for reuse.
It may be so that it runs much faster in release build, but I would not count on it.
Calling a method in another class (such as Math::Cos) prevents a lot of optimizations,
basically the compiler does not trust every call with same argument will return same
result.

PAINT PROBLEM

The way you organized it, the wafer gets painted when you click a menu item or so,
just once. If your form gets disrupted (covered-uncovered, minimized-restored, ...)
(part of) the wafer is gone, what piece of code would redraw it for you ?

The right approach is to have a Paint handler, that gets fired thru the Paint event
(similar to a Click event for a Button). The Paint handler basically should contain
the code you now have in the menu item handler.

The Paint handler gets invoked automatically when the form got damaged, and also
when you call Invalidate().

Hence your menu item handler should just set up a few variables, maybe a show/hide wafer
flag or so, and then it should end on an Invalidate().

Happy painting !

Luc Pattyn [Forum Guidelines] [My Articles]

BuckBrown7-Aug-07 6:24

7-Aug-07 6:24

Hi Luc,

Thank you so much. The speed issue makes sense because when I was doing the same thing in MFC I was doing it a different way that did not use the sine and cosine math functions. I will see about getting a Paint handler to handle the painting instead of the menu item handler. This is the kind of Windows organization that I am not fluent in. I'm usually just happy if I can get something to work. You'll probably be seeing a post later today about printing the screen as I am now venturing into that.

Thanks again,

Luc Pattyn7-Aug-07 6:51