ebergman@isis.cs.du.edu (Eric Bergman-Terrell) (03/04/91)
Is there a bug with SetDlgItemText() in Borland C++ 2.0? I can use SetDlgItemInt() on a dialog box field with no problem. When I try to use SetDlgItemText() on the same field, I can't make it work - it places a "%d" in the specified field, rather than the (literal) string that I pass the fcn. Any ideas? Thanks in advance, Terrell
tmkk@uiuc.edu (Scott Coleman) (03/04/91)
In article <1991Mar4.073605.586@isis.cs.du.edu> ebergman@isis.cs.du.edu (Eric Bergman-Terrell) writes: > >Is there a bug with SetDlgItemText() in Borland C++ 2.0? > >I can use SetDlgItemInt() on a dialog box field with no problem. >When I try to use SetDlgItemText() on the same field, I can't make >it work - it places a "%d" in the specified field, rather than the >(literal) string that I pass the fcn. > >Any ideas? I ran across a nearly identical problem with BC++ 2.0. I was attempting to use SetDlgItemText() with the second parameter a literal string, e.g. SetDlgItemText(hwnd, "Something"); I kept getting either a blank control, a %d, or a '- [%s]' in the item. My solution? I CHANGED THE FILE EXTENSION FROM .CPP to .C, AND NOW THE PROGRAM WORKS!?!?!?!?!?!?! Since I'm relatively new to C++, I thought it might be attributable to some subtle difference in the languages, and temporarily dismissed it. Seeing your message, however, makes me start to wonder... Some more tidbits of info on this problem: calls such as SetDlgItemText(hwnd, strupr(ltoa(0L, szBuffer, 16))); where szBuffer is declared as char szBuffer[20]; work fine, even in .CPP mode. If I try to send it a literal string, or if I try to send it szBuffer directly after putting some characters into it, SetDlgItemText pukes. Anyone else stumble across this one? What's the deal??
cadsi@ccad.uiowa.edu (CADSI) (03/04/91)
From article <1991Mar4.073605.586@isis.cs.du.edu>, by ebergman@isis.cs.du.edu (Eric Bergman-Terrell): > > Is there a bug with SetDlgItemText() in Borland C++ 2.0? > > I can use SetDlgItemInt() on a dialog box field with no problem. > When I try to use SetDlgItemText() on the same field, I can't make > it work - it places a "%d" in the specified field, rather than the > (literal) string that I pass the fcn. > > Any ideas? You sure you gave SetDlgItemText a LPSTR and not a near pointer???
ebergman@isis.cs.du.edu (Eric Bergman-Terrell) (03/07/91)
Yes the string passed to SetDlgItemText was a LPSTR. I found the problem - the fuction wasn't in the export list of the .def file! Terrell
cadsi@ccad.uiowa.edu (CADSI) (03/24/91)
From article <1991Mar15.171838.7689@dbase.A-T.COM>, by awd@dbase.A-T.COM (Alastair Dallas): > In article <1991Mar4.200940.27679@ux1.cso.uiuc.edu>, tmkk@uiuc.edu (Scott Coleman) writes: >> > > I don't have BC++, just ordinary MSC, but I'm wondering if you're compiling > in small model. If so, then a quoted string literal will be passed as > a 16-bit pointer, whereas SetDlgItemText wants a LPSTR. If this is > what's biting you, the following should fix it: > > SetDlgItemText(hwnd, (LPSTR) "Something"); > You know what though, I thought ANSI 'C' states that if you use prototypes, type conversions are automatic. For instance, if you write /* prototype */ double cos(double f); . . . double x = cos(2); then the 2 (integer by default in C) will be automatically type converted to double. Then WHY doesn't the type conversion work for LPSTR above? Am I missing something here (could well be). |----------------------------------------------------------------------------| |Tom Hite | The views expressed by me | |Manager, Product development | are mine, not necessarily | |CADSI (Computer Aided Design Software Inc. | the views of CADSI. | |----------------------------------------------------------------------------|