Professional UI Solutions
Site Map   /  Register
 
 

Forum

Please Log In to post a new message or reply to an existing one. If you are not registered, please register.

NOTE: Some forums may be read-only if you are not currently subscribed to our technical support services.

Forums » Prof-UIS General Discussion » Can a PROF-UIF Dialog based MFC application create a reportgrid as a control inside the dialog? Collapse All
Subject Author Date
miles waldron Dec 29, 2008 - 12:16 PM

This is what I am doing. I am probably doing it wrong. Can someone tell me the right way to do this?


I add a custom control with the class ProfUIS-ScrollItemWindow to the dialog. What I would like to do is add a CExtGridWnd control to the dialog but I do not see how to provide the proper class identification when reviewing the class definition in the header file. I give the control the dialog ID_GRID.


By the way, the sample program PROFUIS_CONTROLS_700 does not work and crashes on my development machine. I am using Microsoft Visual Studio 2005 version 8.0.50727.762 SP.050727-7600 to build with. This sample is where I am getting my clues on how to proceed. I can’t find any official documentation on how to put a grid into a dialog.


Then I declare the following memeber variable in my dialog class.


CExtGridWnd m_cExtGridWnd


Then I add the following to my DDX_Exchange Function


DDX_Control(pDX, IDC_GRID, m_cExtGridWnd);


In my InitDialog function I use the AddAnchor function, and it behaves properly.


AddAnchor(IDC_GRID, __RDA_LT, __RDA_LB);


Then in my InitDialog Function I start adding rows and columns to the grid but it crashes.


 m_cExtReportGridWnd.SiwModifyStyle(__ESIS_STH_PIXEL|__ESIS_STV_ITEM|__EGBS_SFM_FULL_ROWS|__EGBS_RESIZING_CELLS_OUTER|__EGBS_DYNAMIC_RESIZING|__EGBS_MULTI_AREA_SELECTION|__EGBS_NO_HIDE_SELECTION|__EGBS_GRIDLINES|__EGBS_LBEXT_SELECTION, 0, FALSE);


m_cExtReportGridWnd.HoverEventsSet(TRUE, TRUE);

m_cExtReportGridWnd.HoverHighlightSet(TRUE, FALSE, FALSE, FALSE, TRUE, TRUE);


long iCol = 0;

CExtGridCellHeader* pHeaderCell = NULL;


m_cExtReportGridWnd.ColumnAdd(1, TRUE);

pHeaderCell = STATIC_DOWNCAST(CExtGridCellHeader, m_cExtReportGridWnd.GridCellGetOuterAtTop(iCol++, 0L, RUNTIME_CLASS(CExtGridCellHeader)));

 pHeaderCell->ExtentSet(80);

 pHeaderCell->TextSet(_T("MBOL"));


m_cExtReportGridWnd.ColumnAdd(1, TRUE);

pHeaderCell = STATIC_DOWNCAST(CExtGridCellHeader, m_cExtReportGridWnd.GridCellGetOuterAtTop(iCol++, 0L, RUNTIME_CLASS(CExtGridCellHeader)));

 pHeaderCell->ExtentSet(60);

 pHeaderCell->TextSet(_T("BOL"));


long iRow = m_cExtReportGridWnd.RowCountGet();

int iRet = m_cExtReportGridWnd.RowAdd(1, TRUE);


iCol = 0;

CExtGridCell* pCell = NULL;


// CRASH !!! pCell is always NULL


pCell = m_cExtReportGridWnd.GridCellGet(iCol++, iRow, 0, 0);

pCell->TextSet("3");


pCell = m_cExtReportGridWnd.GridCellGet(iCol++, iRow, 0, 0);

pCell->TextSet("4");


 

miles waldron Jan 18, 2009 - 5:05 PM

Is there anyone at your company who performs the job of technical support?


Is there some possibility that I can have my question answered? I do not need a 10,000 word response. What I need is a code snippet that works.


I have uploaded a project that demonstrates the issue, since posting to this list has not been helpful.


http://www.optidoc.com/junk.zip


Again, what can I do to escalate a technical issue? I need your software to function, and not crash.


Again, I need to put your controls into dialog boxes. How is this done? I have explained what I can see many many times. Where are these steps outlined in your documentation?


 

Technical Support Jan 19, 2009 - 1:17 PM

Here is the fixed version of your project:

http://www.prof-uis.com/download/forums/tmp/Junk-fixed.zip

We have changed properties of the custom control on the dialog template resource. It should use the ProfUIS-TabPageContainer window class name instead of the ProfUIS-PageContainer window class name.

We have changed byte alignment option of your test project to default. If you need non-default alignment, then you should compile Prof-UIS library with the same alignment. We recommend you not to use custom alignment in MFC programs to avoid funny problems and spent days for fixing unknown situations.

We also created the simplest possible dialog based project demonstrating how to use the report grid control inside dialog:

http://www.prof-uis.com/download/forums/TestReportGridInDialog.zip

We tried to make it as simple as possible. The CDlg::OnInitDialog() method in this project is the most interesting for you.

miles waldron Jan 16, 2009 - 2:24 PM

I have uploaded a VC++ project to http://www.optidoc.com/junk.zip. This project is created with your wizard as a dialog app. It has one custom control in the dialog. The custom control is a CExtTabControlWnd.


It crashes, and shows exactly what I am talking about. It takes about 3 seconds to verify this is a problem.


I would be very grateful if someone could have a look at this issue.


Thanks!!

miles waldron Jan 16, 2009 - 2:02 PM

Can someone who can understand my question please help me?


Again, all of the above information is very nice, but it does not answer my question.


------------------------> HOW DO YOU PLACE ANY PROF-UIF CONTROL INTO AN MFC DIALOG BOX? <----------------------------------


For example, I want to make a tab page container on the left side of a dialog box.


I add a dialog box resource and class by inserting a new class dervied from CDialog using the MFC class wizard.


In the dialog box resource I drag out a custom control. This appears as a grey rectangle on the dialog.


Inside the properties of the custom control I put the class name of the PROF_UIF control that I want.


For example class = "ProfUIS-PageContainerWnd", and I give it the ID, IDC_TRANSMIT_LAYER, and I make it visible, etc.


Then I add a member variable to the dialog of the proper type. For example


CExtTabPageContainerWnd m_ExtTabPageContainerWnd;


Then I add the following into DDX_Exchange


DDX_Control(pDX, IDC_TRANSMIT_LAYER, m_ExtTabPageContainerWnd);


--------------------------------------------------------------------------------------------------------------------------------


When the dialog box runs DoModal() it *ALWAYS* crashes. It crashes before DDX_Control is even called. It is crashing because the

framework is calling DestoryDialog before it even calls InitDialog. Inside the debugger I can see that deep inside the framework

the Create is failing. It is failing because of the custom control. If I delete the custom control from the dialog, the application

does not crash.


------------------------> HOW DO YOU PLACE ANY PROF-UIF CONTROL INTO AN MFC DIALOG BOX? <----------------------------------

------------------------> HOW DO YOU PLACE ANY PROF-UIF CONTROL INTO AN MFC DIALOG BOX? <----------------------------------

------------------------> HOW DO YOU PLACE ANY PROF-UIF CONTROL INTO AN MFC DIALOG BOX? <----------------------------------

------------------------> HOW DO YOU PLACE ANY PROF-UIF CONTROL INTO AN MFC DIALOG BOX? <----------------------------------

------------------------> HOW DO YOU PLACE ANY PROF-UIF CONTROL INTO AN MFC DIALOG BOX? <----------------------------------

------------------------> HOW DO YOU PLACE ANY PROF-UIF CONTROL INTO AN MFC DIALOG BOX? <----------------------------------

------------------------> HOW DO YOU PLACE ANY PROF-UIF CONTROL INTO AN MFC DIALOG BOX? <----------------------------------

------------------------> HOW DO YOU PLACE ANY PROF-UIF CONTROL INTO AN MFC DIALOG BOX? <----------------------------------

------------------------> HOW DO YOU PLACE ANY PROF-UIF CONTROL INTO AN MFC DIALOG BOX? <----------------------------------

------------------------> HOW DO YOU PLACE ANY PROF-UIF CONTROL INTO AN MFC DIALOG BOX? <----------------------------------


With my 1-year of support is there a place where I can upload an example project that demonstrates this problem?


 


 


 

Technical Support Jan 19, 2009 - 1:17 PM

Here is the fixed version of your project:

http://www.prof-uis.com/download/forums/tmp/Junk-fixed.zip

We have changed properties of the custom control on the dialog template resource. It should use the ProfUIS-TabPageContainer window class name instead of the ProfUIS-PageContainer window class name.

We have changed byte alignment option of your test project to default. If you need non-default alignment, then you should compile Prof-UIS library with the same alignment. We recommend you not to use custom alignment in MFC programs to avoid funny problems and spent days for fixing unknown situations.

We also created the simplest possible dialog based project demonstrating how to use the report grid control inside dialog:

http://www.prof-uis.com/download/forums/TestReportGridInDialog.zip

We tried to make it as simple as possible. The CDlg::OnInitDialog() method in this project is the most interesting for you.

Technical Support Jan 6, 2009 - 12:22 PM

The grid controls are advanced common controls. They are part of Prof-UIS library when button and list box are parts of Windows Common Controls DLL. The methodology is simple: drop required control into dialog template resource or create it as child of any other window, then initialize it and handle it’s events. The difference between grids and list boxes are only in the complexity of grid controls. The best way to learn the grid controls is to look at the sample applications.

In simple words, the grid window is scrollable control displaying data. Here is the general description of the grid windows:

http://www.prof-uis.com/prof-uis/tech-support/feature-articles/prof-uis-grid-brief-overview.aspx

Here are the most often questions asked about grids:

http://www.prof-uis.com/prof-uis/tech-support/faq/data-grid.aspx
http://www.prof-uis.com/prof-uis/tech-support/faq/report-grid.aspx

miles waldron Jan 2, 2009 - 11:53 AM

Thank you very much for the explanation of the different grids and views. In general my problems with your product have to do with documentation, or rather how your concepts are presented. It is very obvious that whomever wrote your product documentation was a thorough person, but the information is not organized well, and there is no general outline that can be followed. Your company might do well to have someone who is good with the English language and English programming concepts redo some of your documentation, but I digress.


This above information is all very helpful, but it does not answer my question.


What are the steps that need to be taken in order to place a CExtReportGridWnd into a dialog as a control?


What is the proper methodology for doing this for the CExtReportGridWind, or any other CExtGridWnd class?


This process should be described in a simple step by step way.


Thank you for your time and attention. I enjoy using your product and I can’t wait to understand how I can use more of it in my development efforts.


Miles Waldron

Technical Support Dec 31, 2008 - 2:55 AM

We believe the custom dialog control is created successfully in your application. But your source code works with report grid like it’s plain grid control. This is not correct.

We have 3 grid controls:

1) The CExtGridWnd class. It implements plain grid control which uses zero based column row/numbers for accessing data and header cells.

2) The CExtTreeGridWnd class. It’s derived from the CExtGridWnd class and implements tree grid control. It uses zero based indices and HTREEITEM row handles. You should use the CExTreeGridWnd::Item***() methods for accessing data cells and header cells at left/right. You should the methods of the CExtGridWnd class for accessing header cells at top/bottom. You can also use the CExtGridWnd class APIs for access all the grid cells including data cells and header cells at left/right, but you will not be able to use these plain APIs for accessing header cells of tree rows under collapsed tree rows. You should not try to use plain grid APIs for adding/removing tree rows. The CExtTreeGridWnd::ItemGetByVisibleRowIndex() and CExtTreeGridWnd::ItemGetVisibleIndexOf() methods allow you to perform the conversion between plain zero based row indices and HTREEITEM row handles. Please note, it’s not possible to get plain zero based index of tree row which is under collapsed tree row (the CExtTreeGridWnd::ItemGetVisibleIndexOf() method returns -1() for such rows).

3) The CExtReportGridWnd class. It’s derived from the CExtTreeGridWnd class and implements the report grid control. This control uses the CExtReportGridItem* pointers as handles of report rows. The CExtReportGridItem* pointer can be used as HTREEITEM handle in invocation of the CExtTreeGridWnd class APIs. If the report row has no children, then it’s the data row displaying cells. If it contains at least one child row, then it’s the group row created dynamically by the grouping/sorting algorithm. The report grid uses the CExtReportGridColumn* pointers as handles of report columns. The CExtReportGridColumn objects are also used as header cells in the top header rows. The report grid control supports active and inactive columns and the CExtGridWnd class APIs can access only grid cells of active columns. You should use the CExtReportGridWnd::Report***() APIs for working with report columns and rows. You should not use APIs of base classes for adding/removing rows/columns. Both the columns and rows can work properly in the report grid control if they are registered using APIs of the CExtReportGridWnd class.

So, please take a look at the report grid initialization in the ReportGrid and FilteredGrids sample applications first. Your report grid initialization code should be similar.

All the grid classes discussed above have many similar features. They are using the same grid cell classes as grid objects and there are no grid cells which cannot be used in particular grid control when can be used in other one. They all support printing/previewing and data sorting. But there are several important differences between them:

1) The cell joining feature is supported by plain and tree grids only.

2) Only the plain grid control supports virtually cacheable mode when only the visible grid cells are instantiated in the application’s memory.

3) Only the plain grid control supports virtual scrolling mode which is used if the row and/or column counts cannot be known or unlimited or cannot be counted.

So, items 2 and 3 mean that only the plain grid control should be used for working with big data ranges. The AdoRecordsetView sample application demonstrates both features of the plain grid control.

4) The data grouping is supported by the report grid control only. The row sorting is supported by all the grids. The column sorting is supported by the plain grid control. If the plain grid control is virtually cacheable or uses virtual scrolling, then it only provides column/row header click events which may cause data sorting, it can display sort arrows but it cannot sort data which is not completely pre-loaded into application’s memory.

5) The column drag-n-dropping and swapping is supported by all the grids when row drag-n-dropping is supported by plain grid only. The column/row drag-n-dropping with inserting cloned copy on drop is not supported explicitly by all the grids. It’s possible to implement the row drag-n-dropping in the tree grid control and it’s not difficult to do. The following test project (http:www.prof-uis.comdownload/forums/test_tree_grid_idea_dnd.zip) demonstrates this. It’s possible to code the same for report grid.

We also have the CExtPropertyGridCtrl class which implements the property grid control and uses the same cell classes for displaying properties of different types. But this class is not really the grid control. It’s container window for several child windows: one or more tree grid windows displaying properties in two columns (property name and property value), toolbar, combo box, help tip window. This control needs to be discussed separately because it’s should not be compared with grids discussed above.