C / C++ / MFC

Get Ctrl Data out of SubForm Dialog to Main Dialog

22-Apr-03 5:07

#include <iostream.h>

fstream Outtxt("myfile.txt",ios::out);

for (int i=0;i<m_List.GetItemCount();i++)
{
  for(int j=0;j<NbItemPerColumn;j++)
  {
   Outtxt<<m_List.GetItemtext(i,j)<<endl;
  }
}

Outttxt.close();

~RaGE();

triggerdie22-Apr-03 4:37

triggerdie

22-Apr-03 4:37

Hi,

While Im using subForms in my Options Dialog, i want to read out the Controls Data, like text out of a CEdit Ctrl. Normally i would do this with DDX and Classwizard -> with result I have a variable which i can use. But with the use of subForms I have no scope anymore to these subForm Dialog Elements.

Im using the SubFormCollection Class from the Article "Child Dialog (Sub Forms)" from D. Zuppinger. [http://www.codeproject.com/dialog/childdlg.asp]

How can i retrieve the Data out of a Control in a SubForm Dialog to my Main Dialog?!

So maybe somebody out there might have an Answer with a little bit of source would be great.

Thanx to all in this community

Andre

Re: Get Ctrl Data out of SubForm Dialog to Main Dialog

Rage22-Apr-03 5:35

Re: Get Ctrl Data out of SubForm Dialog to Main Dialog

22-Apr-03 5:35

I do not know the code, so ...

The subforms are simple dialogs, so you must have a class for each dialog where you can put a member variable the one you meant by with result I have a variable .

Then, I assume the subForms class must have a table of handles or pointers on the different dialogs, or something in this way.

So take the index of your dialog, and try something like :

CDialog *pDlg=(CDialog *)m_SubForms.m_Forms.GetAt(Index);

pDlg->m_myEditCtrl // do your stuff.

~RaGE();

triggerdie22-Apr-03 22:02

triggerdie

22-Apr-03 22:02

Thanx for your fast reply.

I have tried something like this what you have wrote.
Problem of your Code above is that the compiler will generate an error
cause of CDialog has no member m_myEditCtrl. Now i had the Idea to deriver the CDialog Class with my Dialog Class e.g. mySubFormDlgClass. The Code look something like this

mySubFormDlgClass *pdlg = (mySubFormDlgClass*)m_Forms.GetAt(index);

with this Construction there is no error but an Assert @ runtime! So this is not the way. Another Problem is that if i insert some AFX Messages with Classwizard into my mySubFormDlgClass,set breakpoints in this Event Functions and want to debug - there is no interruption. The Event does not occur.

So only a ShowWindow takes places, no DoModal() function. Maybe there is the Problem. If i do a DoModal the Dialog opens but must be closed if i want to use my MainDialog while the other is open. I will research some time on this. Maybe you have some ideas.

Thanks
Andre

Re: Get Ctrl Data out of SubForm Dialog to Main Dialog

Rage22-Apr-03 23:07

Re: Get Ctrl Data out of SubForm Dialog to Main Dialog

22-Apr-03 23:07

triggerdie wrote:
cause of CDialog has no member m_myEditCtrl

... Of course your CDialog has no m_myEditCtrl variable !!! I cannot guess your variable names Roll eyes | :rolleyes:

!! This was only an exemple. Sorry for the misunderstanding. I think the articla was just a basis, you have to work on it to get your data retrieved. The easiest way to do this is the one I gave you. So, let's take it again. Change this in the code of SubFormCollection.h :

instead of

protected:
   CArray<CDialog*, CDialog*> m_Forms; // array with all forms

put

   CArray<CDialog*, CDialog*> m_Forms; // array with all forms
protected:

This will enable you to get at the m_Forms table by setting m_Forms as public.
Now you should have a main dialog, let's say CMainDlg, a CSubFormCollection, and some child dialogs, let's say CChildDlg1 and CChildDlg2 with respectively ressource IDD_SUBFORM1 and IDD_SUBFORM2 (Go in the properties of your dialogs in the ressource editor to set that). Replace these names by your variable names if they are different !!.

First, follow all the steps given in the article, especially step 5 :

CSubFormCollection m_SubForms;

(this in the MainDlg.h file.
and step 6

CRect r;
(GetDlgItem(IDC_SUBFORM_FRAME))->GetWindowRect(&r); // get the position for the subforms
//    m_SubForms.SetRelPos(r);  // if the positioning is absolute use this, else the next line
m_SubForms.SetCenterPos(r);     // centers the subdialog within the static IDC_SUBFORM_FRAME
m_SubForms.CreateSubForm(IDD_SUBFORM1,this); // create the sub forms
m_SubForms.CreateSubForm(IDD_SUBFORM2,this);
m_SubForms.ShowSubForm();

(this in the CMainDlg::OnInitDlg() file.)

Now you have two subForms, with index 0 and 1.
Then, as an example, place an edit box on the ressource of CChildDialog1, open the class wizard, add a member variable m_myEditCtrl of type CEdit.Close the class wizard.

Add a

m_SubForms.ShowSubForm(0);

in your code (in CMainDlg::OnInitDlg() for instance), to show the first subForm.

You can now retrieve the text entered in the edit box by the user with :

CDialog *pDlg=(CDialog *)m_SubForms.m_Forms.GetAt(0);
CString str=pDlg->m_myEditCtrl.GetWindowText();

Ouf

... mail me directly your code if you do not get it to run, i'll be glad to help you further.

~RaGE();

Rage23-Apr-03 23:10

Re: Get Ctrl Data out of SubForm Dialog to Main Dialog

23-Apr-03 23:10

OK. So i made a project and tested the article code, and found out it is totally crap. it is unfinished, sometimes even wrong (under NT, my subFroms were not getting docked in the main dialog) and the Table pointer is not reliable. Dead | X|

Drop it !

As for your code sample, it was because you have cast the pointer on a CDialog, and not on your CDialog name (dlgOpt_ServerPort).

~RaGE();

eXplodus22-Apr-03 8:10

eXplodus

22-Apr-03 8:10

two ways.

first.

on the close routine of the options dialog. you send the text you wand to you parent and save it there.

second.
(i dont take a look on the childdlg.asp) if you use a normal dlg. with DoModal. then create your dialog on the stack not on the heap. mydialog* blub = new mydialog; blub->DoModal(); CString myvar = blub->mycstringvar; delete blub;

Re: Get Ctrl Data out of SubForm Dialog to Main Dialog

Joan M22-Apr-03 21:35

Joan M

22-Apr-03 21:35

I don't know what you mean with SubForm, but if the subform is a dialog placed as a control inside a parent dialog, you can use member functions in the child dialog always...

I mean that is better to use member functions to get the values than getting the values directly by calling SubForm.m_CstringInEditCtrl if you use member functions (GETxxx and SETxxx in order to obtain and modify values) you'll always will be able to readapt the returned value or format the sent value as is desired...

then I would do:
1. from the parent dialog/window/... you'll always have access to the childs.
2. Using the previous premise, you'll be able to call members/methods/functions from the class of the child dialog.
3. I would call methods/functions of the subform in order to get/set the desired values and in order to make it safely.

Hope this helps.

NOTE:
Get and set are only prefixes that I use in order to use the hungarian notation and know what the function do before reading its content.

Re: Get Ctrl Data out of SubForm Dialog to Main Dialog

triggerdie22-Apr-03 22:21

triggerdie

22-Apr-03 22:21

Hello Joan,

Thanx for your fast reply. Is it possible do change dynamicly from the parentsDialog to the ChildDialog without to destroy the ChildDialog.
I want to change the HIDE and SHOW behaviour of several Child Dialogs.
How can I do this? Without using of DoModal() only with ShowWindow().
Cause if i do a DoModal() i can not make any interaction with my parentDialog while the ChildDialog is open. Wihtout a DoModal and just ShowWindow it does not work. Assert @ runtime. So i dont know how to solve this Problem. I want to use the Std Afx Message Functions of each Child Dialog. Maybe you have an advice.

See you

Andre

Question about Int64.

George222-Apr-03 4:26

George2

22-Apr-03 4:26

Hi, everyone!

When reading source code of others, I find they often
use int64 to represent 8-bit integers. I have referenced
MSDN and find the comments there are not enough.

Can anyone tell me where can I find reference about this
topic? Another question, can this data type be used on
Non-windows platform, for example, Linux?

Thanks in advance,
George

Tim Smith22-Apr-03 4:40

22-Apr-03 4:40

The _int64 data type is compiler specific and might not port. However, gcc supports a data type such as LONG LONG.

If you are looking at porting code to other platforms, then anything that must be size specific should be done with typedefs or defines.

Example:

#if defined (WIN32)
typedef _int64 INT64
typedef unsigned _int64 UINT64
#elif define (WHATEVER_LINUX)
typedef long long INT64
typedef unsigned long long UINT64
#endif

Then in your code only use INT64 or UINT64.

Tim Smith

I'm going to patent thought. I have yet to see any prior art.

George222-Apr-03 16:26

George2

22-Apr-03 16:26

Thanks, Tim buddy!

George

John R. Shaw22-Apr-03 16:42

John R. Shaw

22-Apr-03 16:42

First _int64 is Microsofht specific.
Second _int64 represents a 64-bit interger.
If you do a search on MSDN, for _int64, you will find at lease 31 seperate entries. If you search for "microsoft _int64" on google you will find over 200 entries, many of which appear to do with porting. I know of no other sources of information on _int64.

Trust in the code Luke. Yea right!

Pixels - char (difficult)

George222-Apr-03 19:43

George2

22-Apr-03 19:43

Thanks, John buddy!

George

JensB22-Apr-03 3:52

JensB

22-Apr-03 3:52

Hi
I'm inserting all kind of columns in a CListCtrl
with structure LV_COLUMN like this:

ColumnVi = new LV_COLUMN();
CString Title;
ColumnVi->mask = LVCF_TEXT | LVCF_WIDTH;
ColumnVi->fmt = LVCFMT_CENTER;

//Inserting
ColumnVi->cx = 35;
Title = "Nr.";
ColumnVi->pszText = Title.GetBuffer(3); m_PersCtrl.InsertColumn(0,ColumnVi);
//Insert the column into the clistctrl

The width of column i've set to 35, i tested it out and changed the value until it looked good. but the caption can change at some time .. so how can i know how much pixels 1 char. takes or anyone have other ideas to make it more dynamic?

Greetings Jens

Re: Pixels - char (difficult)

Hans Ruck22-Apr-03 4:01

Hans Ruck

22-Apr-03 4:01

You may combine GetStringWidth and SetColumnWidth of CListCtrl.

rechi

Re: Pixels - char (difficult)

Jim Crafton22-Apr-03 4:40

Jim Crafton

22-Apr-03 4:40

get the HDC (or CDC if you are using MFC) and then use the GetTextExtent[^] api call to determine the string length

¡El diablo está en mis pantalones! ¡Mire, mire!

Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!

Crash address, doesn't exist in .MAP file

dandy7222-Apr-03 3:39

dandy72

22-Apr-03 3:39

I have a client reporting that some of my code crashes on a few of his machines; I can't reproduce the problem on my end (what else is new) and all I have to work with is the crash address he's reporting.

I've had a look at Wouter Dhondt's excellent article on .MAP files[^]...and if I'm following the steps properly, the crash occurs in a memcpy() call...great, according to a search in my project's .cpp files, I'm calling it explicitely 74 times. Since I can't reproduce the crash there's hardly any point in stepping through all of them. Besides, if I understand correctly, the call to memcpy() might not necessarily be any of my own (ie, another C runtime library function might be doing it; who knows which one it is).

Taking it to the next step, I tried to determine what file/line the crash occurs in according to the .MAP file. Again based on the article, subtracting the load address (0x00400000) and the 0x1000 bytes PE header from the crash address (0x00459083), I end up with 0x00058xxx, which is nowhere near any of the addresses listed in the bottom part of the .MAP file. And since I'm within 0x004xxxxx, I'm pretty confident the crash doesn't occur in a DLL. I *know* I'm using the proper .MAP file as I've rebuilt the project (this time set to generate the .MAP file) and sent the client the recompiled EXE (which turned out to be identical to the previous one anyway).

I've tried to get the client to send me Dr. Watson logs and crash dumps, but none seem to ever get generated despite the options being selected (he's on Win2K SP2).

What next? I don't like the idea of sending a client an EXE with MsgBox() calls...

Tim Smith22-Apr-03 3:53

22-Apr-03 3:53

Run your release version in debug and and the break the program. Use the debugger to see if you have anything at the address in question. If your release program doesn't have any debug information, it would help to enable the program database debug information.

Tim Smith

I'm going to patent thought. I have yet to see any prior art.

dandy7222-Apr-03 4:28

dandy72

22-Apr-03 4:28

Well...I have *something*, I'm just not sure what it is. Wouldn't this (the memory at the crash address) be in the code segment?

Tim Smith22-Apr-03 4:42

22-Apr-03 4:42

The address you listed does seem like an IP, however if I remember the access violation dialog box, it lists a few numbers including the address being referenced and the IP of the instruction.

I just like using the debugger since reading map files can be confusing a hell. I have been doing it for 20 years and I still get confused.

Tim Smith

I'm going to patent thought. I have yet to see any prior art.

dandy7222-Apr-03 5:10

dandy72

22-Apr-03 5:10

> if I remember the access violation dialog box, it lists a few numbers
> including the address being referenced and the IP of the instruction

That's part of the problem, I don't even get that much info on the crash dialog. Here's the full text (and I just realized I was looking at an old screenshot when I made the original post):

>>>
The instruction at "0x00459083" referenced memory at "0x00c70000". The memory could not be "read".
<<<

According to the .MAP file, the closest function (at 0x004590e0) is memcpy(), and 0x000580e0 isn't part of the .MAP file. So I don't know what to do next...

(I'd kill for a stack trace)

Tim Smith22-Apr-03 6:19