C / C++ / MFC

Re: How do you traverse, or loop through the controls

27-Aug-07 5:57

Dude, I'm a programmer, and programmers are fundamentally lazy in nature (so as not to offend anybody in our overly PC society, allow me to rephrase and state that all the good ones I know display this characteristic). And it serves them well to be that way. Think about it, there could be 300 controls in the header of the screen. Would you want to type 300 hundred Show Window statements. I think not. Also, it would be kind of ugly looking code.

Okay, so I'm exaggerating with the 300 number, but even 3 is one too many. I'd match rather have the ability to step from the low control to the high control and jump over the invalid references along the way.

led mike27-Aug-07 6:36

led mike

27-Aug-07 6:36

littleGreenDude wrote:
the controls located in the header and loop thru them

If they are real child windows you only need the header/parent then there are API's for like FindFirstChild/FindNext etc.

Re: How do you traverse, or loop through the controls

jhwurmbach27-Aug-07 5:49

jhwurmbach

27-Aug-07 5:49

I dont understand your problem fully. Would something like this help you?

for(int lcv = IDC_VENDID; lcv <= IDC_BTNHEADDOWN; lcv++)
{
  CWnd* pCtrl = GetDlgItem(lcv);
  if( pCtrl->IsKindOf(RUNTIME_CLASS(CHeaderCtrl))) {
    pCtrl->ShowWindow(SW_SHOW);
  }
}

Or do you simply need to change the Tab-Order of your controls?

Though I speak with the tongues of men and of angels, and have not money, I am become as a sounding brass, or a tinkling cymbal.
George Orwell, "Keep the Aspidistra Flying", Opening words

Re: How do you traverse, or loop through the controls

littleGreenDude27-Aug-07 6:05

Re: How do you traverse, or loop through the controls

27-Aug-07 6:05

Thank you, that's close to what I was looking for...

The following calls showwindow for all the valid controls

for(int lcv = IDC_VENDID; lcv <= IDC_BTNHEADDOWN; lcv++)<br />
{<br />
    CWnd* pCtrl = GetDlgItem(lcv);<br />
    if( pCtrl )<br />
        pCtrl->ShowWindow(SW_SHOW);          <br />
}<br />

However, for some reason it is still not displaying the header information prior to loading the spreadsheet control. I guess I'll have to post a message to spreadsheet vendor's forum to see what the deal is.

Thanks for the help.

David Crow27-Aug-07 6:01

Re: How do you traverse, or loop through the controls

27-Aug-07 6:01

littleGreenDude wrote:
...header information...

"A good athlete is the result of a good and worthy opponent." - David Crow

"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne

littleGreenDude27-Aug-07 6:09

Re: How do you traverse, or loop through the controls

27-Aug-07 6:09

Sorry, header information - all the labels, edit fields, combos, etc. located above the spreadsheet control on the dialog. Specifically in this case it is a Purchase Order dialog so the spreadsheet consists of inventory items to order and the header is the typical PO header stuff (vendor, PO#, order date, delivery date, terms, shipping, etc.).

David Crow27-Aug-07 6:18

Re: How do you traverse, or loop through the controls

27-Aug-07 6:18

Do those controls happen to be contained within a group control? Or, can you change the controls such that their IDs are sequential? Or, do they all have the same parent?

"A good athlete is the result of a good and worthy opponent." - David Crow

"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne

littleGreenDude27-Aug-07 7:48

Re: How do you traverse, or loop through the controls

27-Aug-07 7:48

Not within a group. I could changed the IDs to be sequential, but I was looking for another solution.

The response provided above, creating a pointer, and if the pointer exists perform a the ShowWindow is the answer I was looking for.

I was told on another forum that the dialog controls actually paint in reverse order of the tab order. Is that true?

David Crow27-Aug-07 8:25

Re: How do you traverse, or loop through the controls

27-Aug-07 8:25

littleGreenDude wrote:
The response provided above, creating a pointer, and if the pointer exists perform a the ShowWindow is the answer I was looking for.

Hence my question about them all having the same parent. However, you indicated here that it did not work.

littleGreenDude wrote:
I was told on another forum that the dialog controls actually paint in reverse order of the tab order. Is that true?

Yes, with certain versions of VS.

"A good athlete is the result of a good and worthy opponent." - David Crow

"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne

Stephen Hewitt27-Aug-07 18:32

Stephen Hewitt

27-Aug-07 18:32

Try code like this:

HWND hwndDialog = GetSafeHwnd();
for (HWND hwndChild=::GetWindow(hwndDialog, GW_CHILD); hwndChild!=NULL; hwndChild=::GetWindow(hwndChild, GW_HWNDNEXT))
{
	// Do something with "hwndChild" here...
}

Steve

PDA communication

Waldermort27-Aug-07 5:34

Waldermort

27-Aug-07 5:34

Does anybody know of any good articles about communication with a PDA attached to the PC?

I have an EASTCOM ES2100 ( Chinese brand ) PDA with a Hopen 2.0 OS. Now the guys at Hopen have created an SDK for this OS but I have no way of installing my software on the PDA. I'm going to have to create a windows driver to connect to open a port to the device, but after that I have no idea as to what to do.

I do know that the OS is based on Linux is thats of any use :/

Re: PDA communication

Matthew Faithfull27-Aug-07 8:04

Matthew Faithfull

27-Aug-07 8:04

I'm no Linux expert but if Hopen is Linux based I would expect it to be running server type services of some sort telnet, ssh or even vnc. I'd start from there, consider what type the physical ports are at either end and see what 3rd party tools like USB serial drivers or PUTTY you could use.

Nothing is exactly what it seems but everything with seems can be unpicked.

pointer on char array

baerten27-Aug-07 3:35

27-Aug-07 3:35

Hi everybody,

i made a buffer-CEdit where i rely a char* with a CEdit.

how can i store the char* from the View into the CEdit?

i create the View-Variables like this:
char *var = (char*)malloc(sizeof(char)*50);

My own CEdit derived texbox:

MyCEdit tbNumber  (Creation via DDX)

then i "link" the string with the Textbox

tbNumber.Link(&var);

where MyCEdit has a

char** InternBuffer;

and the "linkage" is made this way:

void MyCEdit::Link(char** var_t)
{
  InternBuffer = var_t;  
}

But it doesn't work, i tried some other possibilities, but i always get another pointer value Sigh | :sigh:

There is seriously a simple * mismatch

Thanks for help Smile | :)

David Crow27-Aug-07 3:41

27-Aug-07 3:41

Why are you doing this? One of the major selling points of using MFC is that you don't need to mess around with char-type variables, especially where the memory manager is concerned.

if you need the txt within an edit control, simply use:

CString str;
tbNumber.GetWindowText(str);

"A good athlete is the result of a good and worthy opponent." - David Crow

"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne

baerten27-Aug-07 4:03

27-Aug-07 4:03

Thanks for your answer,

i like to develop this kind of trading to minimize the lines of code.

at the window i have class-member strings which are always up-to-date with the
content of the textbox.

Because if i have 10 textboxes on a view and they'll filled with data from out a database
then the user can modify the content and at the destruction of the view all the contents of the
textboxes are re-stored into the database.

In this case i have to GetWindowText 10times and SetWindowText 10times.

If the view performs other special functionalities i Get/Set more than 2-3times.

Since now i always do it in your way, but i try to keep the DOS-Programming way, for that
my work-partners, which works only in DOS programming could understand more faster my application.
Because i copy the existing DOS-Applic 1:1 into MFC
And i don't have the time to change all the logic from DOS-to-Windows Programmatic-System Sigh | :sigh:

I know that all this is strange, but it's my work Wink | ;)

David Crow27-Aug-07 4:39

27-Aug-07 4:39

I fail to see what any of this has to do with using char* rather than CString variables. If your coworkers are unable to work with CString, then they are also unable to work with CEdit.

"A good athlete is the result of a good and worthy opponent." - David Crow

"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne

Russell^'27-Aug-07 3:49

Russell^'

27-Aug-07 3:49

baerten wrote:
tbNumber.Link(&var);

I really hope that var isn't a local variable, elseway InternBuffer (=&var) become soon unuseful.

Russell

baerten27-Aug-07 3:57

27-Aug-07 3:57

Nope, var is in this case a class-member and if not, anyway allocated dynamically via malloc

thanks anyway for help Smile | :)

Russell^'27-Aug-07 4:14

Russell^'

27-Aug-07 4:14

Then it seems that it must work.
Can the problem be on the way you get the value?

char Val=(*InternBuffer)[MyPreferredCharInTheString];

Russell

Re: Strange

baerten27-Aug-07 4:26

27-Aug-07 4:26

i perform into Link(char **var_t) :

void MyCEdit::Link(char** var_t)
{
InternBuffer = var_t;
SetWindowText(*var_t);
}

then i get an error into the message loop of the window-thread

if i set the InternBuffer = var_t; line as comment :

void MyCEdit::Link(char** var_t)
{
//InternBuffer = var_t;
SetWindowText(*var_t);
}
it works and the textbox gets the correct string. And no error occurs.
If i re-insert the InternBuffer = var_t; line it crashes during a message loop, for example
with a SetText-Message or Paint-Message of a pWnd->WindowProc(....

Thats the strange action, my "pointer problem" is correct

Re: Strange

Russell^'27-Aug-07 4:47

Russell^'

27-Aug-07 4:47

I haven't enough information. Frown | :(

But are you sure that you can't use an internal buffer like this:

char* InternBuffer ;

It seems the simpler way: i.e. a simple string, I think that your problem cames somwhere in your code from your char** solution. Confused | :confused:

Russell

Re: Strange

baerten27-Aug-07 5:12

27-Aug-07 5:12

Ok, InternBuffer is set to char*

initialised via "InternBuffer = var_t;" and NEVER used...

InternBuffer = var_t; --> makes problem
//InternBuffer = var_t; --> no problem

Sometimes i have some strange error that i think there is a huge bug in my whole project Confused | :confused:

KarstenK27-Aug-07 4:13

KarstenK

27-Aug-07 4:13

char** => char* should do the work.

Wouldnt it be easier to give the MyCEdit a public char[] member?

Greetings from Germany

baerten27-Aug-07 20:59