|
seems to me that there is one "accepted" way of presenting settings/preferences to the user, in a dialog box with some tabs; which is the Microsoft way.
either that or the other more "linux" way which is to replace the tabs ( situated at the top ) with a list of items ( with/out graphics ) on the left of the dialog ( like in firefox )
any other ways ? prefered ways ?
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
MY personal preference is the Mozilla way - you have a tree-like structure of main pages on the left, and clicking on a node shows options for that item on the right. This is good if you have a ton of stuff. If you just have a few preferences, a regular old PropertySheet is probably best.
The bigger question is where to put the "Preferences..." menu option so your users can even find it. There doesn't seem to be a good standard for that.
"Fish and guests stink in three days." - Benjamin Franlkin
|
|
|
|
|
Navin wrote:
The bigger question is where to put the "Preferences..." menu option so your users can even find it. There doesn't seem to be a good standard for that.
I tend to use Tools | Options... which seems to be the replacement for the old File | Preferences... menu item.
/ravi
My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
Tabs are better so long as you can get by with only one row of tabs. (Microsoft fails this all the time)
The linux way comes from the idea that you should give users a million options and let the user choose what to do. There is no good UI for doing this (at least not that we know of), the linux thing is a compromise, hard to figure out, but once you know how it works it is easy to find the option you are looking for.
If you can't get by with one row of tabs see if there is a small set of things the user is likely to want to change, and put that on a different screen and make it easier to access. The rest should be called advanced settings and placed in the linux style control.
|
|
|
|
|
in my project, when the dialog box (window) is initialized( i,e Onintdialog())the "ok" button is disabled, and i want it to enable automatically after 8 seconds. plz can any one guide me to enable the button after 8 seconds...
|
|
|
|
|
Create a timer in the OnInitDialog() handler. In the OnTimer() handler, enable the OK button and kill the timer.
/ravi
My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
OnInitDialog() :
((CButton*)GetDlgItem(IDOK))->EnableWindow(FALSE);
SetTimer(100 <font style="color:green;"></font>, 8000 <font style="color:green;"></font>, NULL <font style="color:green;"></font>);
<font style="color:green;">
OnTimer(UINT nIDEvent) :
<font style="color:blue;">if</font> (nIDEvent == 100) {
((CButton*)GetDlgItem(IDOK))->EnableWindow(TRUE);
KillTimer(100);
}
TOXCCT >>> GEII power
|
|
|
|
|
Hi,
how can i show an existing image in a c++ window. I mean i want my code to open a window and display an existing image in that window.
In a future work i will try to show an image sequence in that window.
For example, i have image001.bmp, image002.bmp,.. image016.bmp.
I want to open a window and display the images as a slide show in that window. Maybe going to the next image can be assigned to pressing a key on the keyboard. Or maybe a time feature could be used. I mean, in the window, existing images will be displayed each 0.5 seconds with the same order in the sequence.
Could someone help me with an explanatory piece of code?
Thank you ...
|
|
|
|
|
nyquisttt wrote:
how can i show an existing image in a c++ window. I mean i want my code to open a window and display an existing image in that window.
Use a static control and draw the image on it.
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
Hi all,
I have an app that uses FindWindow to find the window handle to another app's window, and it looks like it is hanging. It doesn't do it every time, but from my logging statements, I can tell that FindWindow is the last thing called when it's hung up.
I've seen the various articles/comments about the dangers of using FindWindow, ie: uses SendMessage internally & can hang if another app's thread is waiting/hung, etc.
I have written an alternative function for some other purpose that works similarly to FindWindow but checking all the top level windows, starting w/ the desktop window, but that too uses GetWindowText (ie: SendMessage()) & I think will have the same liability.
My question is: What's a good alternative to using FindWindow ?
I would alter my similar function to use SendMessageTimeout, but I am using Windows CE, and that function is not supported.
Please help, won't you?
What are the alternatives to using FindWindow?
here are some details about how I'm using FindWindow
LPCTSTR szPossibleNames[] =
{ _T("name1"), _T("name2"),...,_T("nameN") };
for(int i=0; i < X; ++i)
{
if( FindWindow(NULL, szPossibleNames[i]) )
break;
}
Is using FindWindow in a loop like this just asking for trouble? It's like I'm making it do risky things over & over again....
Just for fun, and in the case it can help somebody point out an alternative to me, here's the code for my 'alternative func':
HWND FindChildAmongManyChildDialogs(HWND hWndMain,
LPCTSTR szClassName,
LPCTSTR szWindowTitle)
{
CString str, strTitle;
TCHAR szClass[ 200 + 1 ] = {0};
CWnd * pChild = CWnd::FromHandle(::GetWindow(hWndMain, GW_CHILD) );
CWnd * pLast = NULL;
if( pChild )
pLast = pChild->GetWindow(GW_HWNDLAST);
if( !pChild )
return NULL;
do{
GetClassName(pChild->GetSafeHwnd(), szClass, 200);
pChild->GetWindowText(strTitle);
if(_tcsicmp(szClass, _T("Dialog")) == 0 )
{
HWND hChild = FindChildWindow(pChild, szClassName, szWindowTitle);
if( hChild )
return hChild;
}
pChild = pChild->GetWindow(GW_HWNDNEXT);
}while( pChild && (pChild != pLast) );
return NULL;
}
HWND FindChildWindow(CWnd * pParent, LPCTSTR szClassName, LPCTSTR szWindowTitle)
{
ASSERT( szClassName || szWindowTitle );
ASSERT( pParent );
CString strTitle;
TCHAR szClass[ 200 + 1] = {NULL};
CWnd * pChild = pParent->GetWindow(GW_CHILD);
ASSERT( pChild );
CWnd * pLast = NULL;
if( pChild )
pLast = pChild->GetWindow(GW_HWNDLAST);
if( !pChild )
return NULL;
do
{
GetClassName(pChild->GetSafeHwnd(), szClass, 200);
pChild->GetWindowText(strTitle);
if( (!szClassName || _tcsicmp(szClass, szClassName) == 0)
&& (!szWindowTitle || strTitle.CompareNoCase(szWindowTitle) == 0) )
{
return pChild->GetSafeHwnd();
}
pChild = pChild->GetWindow(GW_HWNDNEXT);
}while( pChild && (pChild != pLast) );
return NULL;
}
Last question:
Is using FindWindow(_T("dialog"), <window title="">)
better than using FindWindow(_T("dialog"), <window title="">) ?
Does specifying the class name prevent it from using the sendmessage call internally for those cases where the window is obviously not a dialog?
Thanks! Any help would be swell.
Wes
|
|
|
|
|
Wes Jones wrote:
have an app that uses FindWindow to find the window handle to another app's window, and it looks like it is hanging.
You are correct about FindWindow()'s use of SendMessage() and the deadlock that can occur.
Wes Jones wrote:
My question is: What's a good alternative to using FindWindow ?
That all depends on what you are wanting to do.
Wes Jones wrote:
Last question:
Is using FindWindow(_T("dialog"), )
better than using FindWindow("dialog", ) ?
"Better" depends on if you are using Unicode or not. The _T() macro will work in either case as the preprocessor will resolve it accordingly.
Wes Jones wrote:
Does specifying the class name prevent it from using the sendmessage call internally for those cases where the window is obviously not a dialog?
What if two windows have the same class? FindWindow() is still no help.
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
Hi, thanks for the reply.
DavidCrow wrote:
That all depends on what you are wanting to do.
What I'm trying to do is...
I am writing an app on A CE device, and it uses a wireless modem to connect to the internet so that it can communicate w/ a server....
My code is trying to make it easy for the user by starting/stopping the modem software at the apprpriate times.
Before starting the modem, I look for the window titles for the various versions of the modem software that we support, and if it's already thereI won't start the modem software,
If I'm trying to close the modem, I try to get the handle to the window so that I can post the WM_CLOSE or appropriate messages to get the modem software to exit.
I support doing this for the Sierra Wireless AirCard 300, 555, 710, and 750 modems.
I wrote
Last question:
Is using FindWindow(_T("dialog"), )
better than using FindWindow("dialog", ) ?
Oops, meant to put the _T() macro on that last one there...
I guess my hope there is that I'd be cutting out of the equation any windows that aren't "dialog", even though it's not 100%.
I've found w/ Spy++ that some versions of the modem software creates two top level windows w/ the same title.... not ideal, but I've been getting around it.
|
|
|
|
|
A better alternative - if you just want to communicate - is to use kernel objects. Take a look at some of the articles here on CP in the Threads and IPC section. I'm not sure which kernel objects CE supports, but hopefully that will put you in the right direction.
Now, this will only work if you own all processes/windows in question. If you don't... that is, you are looking for some system or 3rd party window, you are pretty much relegated to hacks, unless the apps in question have a published/well-defined way to communicate with them. By hacks I mean, using FindWindow and hardcoding the window text (bad idea becuase FindWindow can hang, and the window text could change.)
"Fish and guests stink in three days." - Benjamin Franlkin
|
|
|
|
|
Hi Navin,
Yeah, it's w/ a 3rd party app that I'm tryin to get at, and as it's my luck that there are no such well defined ways to doin it.
Something that could be of help.... is anyone aware of a way to test if a window will respond to SendMessage? Normally, SendMessageTimeout would allow me to figure out that the window isn't responding, and I would ignore it... but w/ CE that handy function isn't available. What's another way to know if it won't respond?
Thanks!
|
|
|
|
|
And actually, it may be worse than just the problems you are seeing. If that 3rd party app is translated into any languages that you aren't (e.g., the dialog title will change), again you're screwed.
"Fish and guests stink in three days." - Benjamin Franlkin
|
|
|
|
|
Can you accomplish what you need by enumerating the task/process list?
Neville Franks, Author of ED for Windows www.getsoft.com and coming soon: Surfulater www.surfulater.com
|
|
|
|
|
That would work (using the CreateToolhelp32Snapshot & APIs) for seeing if it's already running, but there are still cases where I'll need the window handle...
I think mix of that & using GetWindowThreadProcessId() might help me out.
Thanks!
|
|
|
|
|
Wes Jones wrote:
That would work (using the CreateToolhelp32Snapshot & APIs) for seeing if it's already running, but there are still cases where I'll need the window handle...
If I recall correctly there are ways to get the main window handle for a process.
I've just bought my first PDA and am reasonably impressed. However I don't think I'll be doing any programming for it any time soon.;)
Neville Franks, Author of ED for Windows www.getsoft.com and coming soon: Surfulater www.surfulater.com
|
|
|
|
|
1. How they can call a type(class name) CObject.
As long an object is an instance of a class,
How they can call a class 'CObject' ???
2. Extreme encapsulation!!!
-I've seen this in MFC/ATL implementations:
If they have C++ classes usually they make data members
private and provides public functions for access
Them as read/write (Set***(), Get***), so instead writing
obj.member=5; you write obj.SetMemebr(5); and
type t = obj.member; you write type t = obj.GetMember().
-On the other hand when you use some COM components type libraries
By default (!raw_interfaces_only) they wrap the ccom_ptr
In the *.tli generated files around the interfaces 'transforming'
The interface method calls (__declspace(propput=)...)
po->SetVar(type) into po->_var=type; which is the other way around.
So finally the cool thing is when we have the possibility of right member access we wrap function calls and when we have function calls
We wrap direct member access call. Isn’t this weird?
|
|
|
|
|
( is it a rant or a question ? )
suiram40 wrote:
1. How they can call a type(class name) CObject.
Why not ? I can call my base class CPotato if you want ...
suiram40 wrote:
2. Extreme encapsulation!!!
for the first part, Yeah, this is the way to do OO programming ( IMHO ), to privatize data members, and have setters and getters.
why ? because it's safer. clearer.
if for some reason, you decide to change the name of the variable; you will need to change it everywhere, with getter/setters, you only change the class.
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
Maximilien wrote:
I can call my base class CPotato if you want ...
Yes, but would it be able to handle ketchup (for frenched fries), or butter (for mashed)? I like both styles so these accommodations are a requirement!!
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
|
'CPotato' and any other specific category is right fine, but CObject ???
|
|
|
|
|
suiram40 wrote:
but CObject ???
Why not CObject? It is the least common denominator.
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
For point two:
Imagine a simple circle class. You have setters and getters for Area, Radius, and Diameter. Simple grade school math gives the relation between them. Now which are you going to store in your class? If you use setters and getters it doesn't matter because you can change it at anytime without anyone else being affected. (and a good compiler will inline them so there isn't overhead)
Think it doesn't matter? Say you pick area. Well I'm going to use your class, but after a profiler I've discovered that getting the diameter is taking a large part of the CPU time, and the system is too slow. A simple change to the class to store diameter will speed things dramaticly. Of course if you anticipated area being most needed, then area would be right. (even though square roots are slower than powers in general)
Of course the example I gave is contrived. You should get the idea though. In the real world it often turns out that you don't know in advance what you will need to change latter so you use getters and setters everywhere just in case. 95% or more of the time you will never change it, but overall you have saved yourself a lot of work with the getters and setters.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
