|
|
Greetings,
I am currently using Microsoft Visual C++ to develop a GUI/UI for an I2C Read/Write program. Right now, I have a dialogue box implemented (a Resource file [.rc] that I included in the project). I believe I have the edit boxes working fine, where the user can enter certain parameters into blank boxes (i.e. start address, how many bytes), but the thing is, I have no way to check internal variables in my program, because there doesn't seem to be a way to "printf" values to the screen with a dialogue box.
Therefore, my essential question is: how do I output certain internal variables to the screen if I'm using a dialogue box interface? I essentially am looking for a "window" into my internal variables, maybe some type of text/edit box that continually "updates" with a new value of my internal variable - just something equivalent to a "printf" statement, but for a dialogue GUI box. Does anyone know how to do this? Any insight into this problem would be greatly appreciated.
Best Regards,
Tim Hsieh
Trex Enterprises
|
|
|
|
|
Try TRACE or search for TraceWnd.
__________________________________________
a two cent stamp short of going postal.
|
|
|
|
|
pADOLogin is never defined, which is passed into GETRS. any ideas how the compiler or the runtime know what to do with pADOLogin a.k.a. db?
CString strSQL = "SELECT * FROM Login WHERE User_Name='" + m_strUserName + "'";
BOOL bLogin = VALIDATE_USER;
GETRS(pADOLogin, strSQL, m_strUserName, this);
#define GETRS(db, sql, user, pcs) \
CDBTier db;\
OPENRS(db, sql, user, pcs)
#define OPENRS(db, sql, user, pcs) \
TRY{\
WriteToLog(sql, user, __FILE__, __LINE__);\
db.CreateDispatch("WorkFlowDBTier.DBTier.1");\
if (db.m_lpDispatch != NULL)\
{ db.Open(0, m_strDataSource, user);\
if (m_bContentStarted)\
pcs->WriteResponseDebug(sql + CString("
"));\
db.OpenRecordset((COleVariant)sql);\
}\
else\
{ WriteToLog("\r\nUnable to Create DBTier Dispatch", user, __FILE__, __LINE__);return FALSE;}\
}CATCH_ALL(e)\
{\
WriteToLog("SQL Error:" + CString(sql), user, __FILE__, __LINE__, e);return FALSE;\
}END_CATCH_ALL
<signature>
It's good to live,
Josef Wainz
Software Developer
|
|
|
|
|
Have you tried placing the cursor on pADOLogin and pressing the F12 key? This should take you to the definition.
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
From the code GETRS(db, sql, user, pcs)
becomes
CDBTier db;
OPENRS(db, sql, user, pcs) // Note I have not expanded the OPENRS bit
Therefore pADOLogin is defined as a CDBTier object.
Ant.
I'm hard, yet soft.
I'm coloured, yet clear.
I'm fruity and sweet.
I'm jelly, what am I? Muse on it further, I shall return! - David Williams (Little Britain)
|
|
|
|
|
Thanks for your response. Normally functions and there prototypes require the datatype to be included in the function statement. I expected:
OPENRS(CDBTier db, CString sql, CString user, CString pcs); instead of OPENRS(db, sql, user, pcs)
Can you explain why this type of declaration isn't necessary?
<signature>
It's good to live,
Josef Wainz
Software Developer
|
|
|
|
|
In your example there isn't a function declaration it is a defined MACRO. When you use MACROs they are replaced with their associated code before compilation.
In your example I am not sure why MACROs have been declared as such. IMO they are un-necessary here. You could change the code to remove the macros and have appropriate functions to do the work for you.
I feel that it would be easier to maintain and understand if you made such changes. Not just for yourself, but for others that may need to maintain the code in future.
Ant.
I'm hard, yet soft.
I'm coloured, yet clear.
I'm fruity and sweet.
I'm jelly, what am I? Muse on it further, I shall return! - David Williams (Little Britain)
|
|
|
|
|
Is there an Windows API that I can use to extract the server's comment? For example, given server name //server1, I need its comment, such as Dave's fastest PC.
Thanks.
|
|
|
|
|
Sure, just use NetServerGetInfo(_T("\\\\server1"), 101, ...).
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
Does anyone know a good way to determine if a CWnd* represents a group box?
Joel Holdsworth
|
|
|
|
|
Group boxes are button controls with the BS_GROUPBOX style flag set.
So, the easy way would be to use the CWnd pointer to get the style flags (CWnd::GetStyle) and see if the DWORD contains BS_GROUPBOX. If it does, then it's a group box.
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
Yes but I seem to get "false positives" on things like static controls which also have the same flag set, but with different context... any ideas?
Joel Holdsworth
|
|
|
|
|
GetClassName should help you out. IIRC, you're looking for the class "BUTTON".
Stability. What an interesting concept. -- Chris Maunder
|
|
|
|
|
How are you checking for the BS_GROUPBOX style?
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
yes, but I seem to get some control's (like statics) which have that style set even though they are of course not groupboxes!
Joel Holdsworth
|
|
|
|
|
But are you checking for that style using the equality operator or the bitwise AND operator? It makes a big difference.
Otherwise, you'll also need to compare the class name as has already been suggested.
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
AFAIK I'm using the & operator.. although I don't have code in front of me to check it.
Joel Holdsworth
|
|
|
|
|
Check these two things:
1. Check for the style flag (BS_GROUPBOX)
2. Check the class name ("BUTTON")
It should be pretty fail-safe. If nothing else helps, then use Spy++ to get the style DWORD value of the group control and do a direct comparison. If you're using Dialog Editor to create your dialogs, it always creates "similar" group box controls.
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
I do not know if you figured this out already, but this is the code I use
(pWnd->IsKindOf(RUNTIME_CLASS(CButton))) &&
(((pWnd->GetStyle()) & BS_GROUPBOX) == BS_GROUPBOX)
BS_GROUPBOX is defined as 0x7 ( 0111 in binary ) so it is a combination of bits. Using just GetStyle() & BS_GROUPBOX will return a positive value if any one of the three bits are set (ie for BS_DEFPUSHBUTTON, BS_CHECKBOX, BS_AUTOCHECKBOX and BS_RADIOBUTTON). By checking for equality you ensure that all three bits are set.
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
"Obviously ??? You're definitely a superstar!!!" mYkel - 21 Jun '04
Within you lies the power for good - Use it!
|
|
|
|
|
Does anyone know a good way to prevent Alt+F4 from exiting my MFC app?
Joel Holdsworth
|
|
|
|
|
Is there any specific reason of why you'd need to prevent these hotkeys ?
Alt+F4 (and CTRL+F4) are considered as global, all-working hotkeys to close Windows applications. They are available as "last resort" commands to close down a non-functioning or an incorrectly running application, and as such, they shouldn't be disabled for light reasons.
A more effective way is to implement an "application closing" handler (WM_QUIT) that will tell the user to save open documents and/or warn the user if it is unwise to exit the application at this moment.
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
Yeah I know [sigh], I'm aware of the windows standard, but there's a fairly good reason to break the rules in this context... I'm writing software to control 30-40 hydraulic jacks, each designed to carry around 800 tonnes. The idea here is that the interface is really dumned down, and only a few very select hot-keys are implemented. And the idea of the app exiting halfway through a lift is very undesirable (despite the fact that you'd have to be really stupid to press Alt+F4 while working on this thing). The customer has requested the keys to be surpressed, so I can't really get around this! 
Joel Holdsworth
|
|
|
|
|
Alt+F4 sends, IIRC, a WM_SYSCOMMAND message with the SC_CLOSE flag. If you allow that to propogate down to DefWindowProc, it gets turned into a WM_CLOSE, which in turn if not handled by you ends up in DefWindowProc which calls DestroyWindow.
You can intercept the WM_CLOSE message and simply not do anything. Yes, it's evil  Windows won't try to kill off your app, or bring up the 'End Task' dialog, because you're still handling messages. Assuming this is XP. I hope it isn't, because XP doesn't have any kind of real-time guarantees, so you'll have unpredictable response times to interrupts. If you're using a real-time kernel with XP, feel free to ignore me.
Stability. What an interesting concept. -- Chris Maunder
|
|
|
|
|
Well, I do still want to allow exiting, just not by the Alt+F4 method. As for using WM_SYSCOMMAND... will that still allow closing from the close button or sys menu?
Joel Holdsworth
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
