|
I want to achieve the following:
Suggest you have a property sheet with three property pages which all have a combobox named IDC_COMBOBOX. The comboboxes named IDC_COMBOBOX, all have te same items stored in it. The list of items is large, so it takes a wile to put (initialize) all the items into the combobox. Therefore I want all the three comboboxes to share the same list of items, so that I only have to initialize one time to get all the three comboboxes filled with the same items.
How can I achieve this?
Is there a way to access the storage of the combobox from another dialog?
Thnxx
|
|
|
|
|
harmendejong wrote:
Is there a way to access the storage of the combobox from another dialog?
yes.
first of all, you should determine DDX object for your control(m_combo) in CYourDialog1 and then you can access to control from other dialog that follow this.
CYourDialog1 dlg;<br />
dlg.m_combo......
|
|
|
|
|
On that way I can access the data of the other combobox, but actually I want al the (three) comboboxes to act like they are the same. So if I've added a large list of items to combobox1, then combobox2 and combobox3 must automatically have that items too without having to load the large list of items into their storage area in the memory. I think this could be done if they all use the same area of memory for the storage of their items.
How can this be done???
|
|
|
|
|
harmendejong wrote:
Is there a way to access the storage of the combobox from another dialog?
No, you can't have two combo boxes share the same data. However, to speed up the loading process, use SetRedraw() on the combo boxes (if you're using MFC, send the WM_SETREDRAW message to the combo box if you're not) to prevent the combo box updating itself after each addition. Remember to call it again when you've finished loading data to enable updating again, and then call Invalidate() on the combo box.
Hope this helps,
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Correct me if I am wrong, but he can create a combo box at run time, initialize it, hide it, and then whenever a dialog gets the focus or created he can show that combo box at the appropriate position. I have done something similar (not exactly the same) with edit boxes on a grid but I kind of aborted the project (for other reasons). It requires some work and it might not be very feasible.
// Afterall, I realized that even my comment lines have bugs
When one cannot invent, one must at least improve (in bed).-My latest fortune cookie
|
|
|
|
|
Can you please give me some sample code of what you mean??
Thnxx
|
|
|
|
|
 That was just an idea harmendejong so I really don't have any source code (I don't even know if it works).
But here is a general idea of how it might be implemeted (the code has not been tested at all, and it needs to be modified to work).
CRect aRect( 0, 0, 10, 10 );
m_cmbMyCombo.Create(WS_CHILD | WS_VISIBLE |
CBS_DROPDOWNLIST,
aRect, this, IDC_MYCOMBO );
...
m_cmbMyCombo.ShowWindow( SW_HIDE );
aRect = SomeArea;
m_cmbMyCombo.SetParent( this );
m_cmbMyCombo.MoveWindow( &aRect );
m_cmbMyCombo.ShowWindow( SW_SHOW );
m_cmbMyCombo.SetFocus();
You have to make sure that you hide and show your combo box accordingly. You won't be able to handle the events through the class wizard (unless you create your own combo class derived from CComboBox). Also, you have to make sure that you destroy the combo box at the end.
Sorry, I can't help you anymore because this is something that I haven't tested but I hope that it gives you some ideas on how to proceed.
// Afterall, I realized that even my comment lines have bugs
When one cannot invent, one must at least improve (in bed).-My latest fortune cookie
|
|
|
|
|
Yes, it's technically possible, but it's a logistical nightmare . It's a bit more difficult that moving one edit box around on a single page.
All the combo box messages are sent to the parent of the combo box, such as selection change, edit change, focus change etc. Yes, the parent can be changed dynamically to the different pages (using SetParent()) but it's not much more than a hack, and makes it virtually impossible to use ClassWizard (not much of a limitation, but depending on his skill with VC++ it may be).
The selection of the combo box can be different on each page, and will need to be saved and restored every time a new page is displayed.
Basically, it's more work to keep track of one combo box on multiple pages than it is to try to speed up the loading process.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
harmendejong wrote:
Suggest you have a property sheet with three property pages which all have a combobox named IDC_COMBOBOX. The comboboxes named IDC_COMBOBOX, all have te same items stored in it. The list of items is large, so it takes a wile to put (initialize) all the items into the combobox. Therefore I want all the three comboboxes to share the same list of items, so that I only have to initialize one time to get all the three comboboxes filled with the same items.
How can I achieve this?
Have the property sheet keep the data in a list or array of some sort. Then in the OnSetActive() method of each property page, populate its combobox with the data from the property sheet. Make sense?
|
|
|
|
|
Hi,
can any body help me in creating a username and password for the database programmatically.I am connecting to the database like this:
CString sDriver = "MICROSOFT ACCESS DRIVER (*.mdb)";
CString sDsn;
TCHAR sError[100];
sDsn.Format(_T("ODBC;DRIVER={%s};DSN='';DBQ=%s"),sDriver,sDatabase);
try
{
m_pDatabase->Open(NULL,false,false,sDsn);
}
catch(CDBException* e)
{
e->GetErrorMessage(sError,100);
AfxMessageBox(sError);
}
|
|
|
|
|
I'm not sure about Access but isn't this accomplished using something like:
GRANT CONNECT TO FRED IDENTIFIED BY SESAME
BTW, why don't you just:
e->ReportError();
instead of
e->GetErrorMessage(sError,100);
AfxMessageBox(sError);
Rgds,
S. Bro
|
|
|
|
|
read msdn "SQLDriverConnect (Access)"
there you will see, that the UID and PWD keywords are supported...
use sDsn.Format(_T("ODBC;DRIVER={%s};DSN='';DBQ=%s;UID=%s;PWD=%s"),sDriver,sDatabase,sUser,sPass);
i don't know if this works, it's just an idea.
good luck
Don't try it, just do it! 
|
|
|
|
|
How to prevent binding a Type library to a ATL Attributed DLL ?
need help
ty
tal halfon
|
|
|
|
|
Hello everyone!
Please look at the follow sample,
--------
fd = open (...);
switch (fork())
{
case child_process:
use fd to read;
close (fd);
break;
case parent_process:
use fd to write;
wait (NULL)
break;
}
--------
I think the case is not correct. I think closing fd by child process is
not the same as closing fd by parent process. So I think the parent
process should also close fd before termination.
Am I correct?
Thanks in advance,
George
|
|
|
|
|
George2 wrote:
Am I correct?
Yes. Both processes need to close the file descriptor. You also might want to use waitpid() instead of wait(), especially if you are using multiple child processes.
Hope this helps,
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Thanks, Ryan buddy!
I have another sample. It is from the well known miniterm.
I think the parent process should close fd and reset the properties of /dev/modem, and stdout, and close /dev/modem even if the clild process has done
that. Am I correct?
Code:
--------
/*
* AUTHOR: Sven Goldt (goldt@math.tu-berlin.de)
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
*/
/*
This is like all programs in the Linux Programmer's Guide meant
as a simple practical demonstration.
It can be used as a base for a real terminal program.
*/
#include <termios.h>
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/signal.h>
#define BAUDRATE B38400
#define MODEMDEVICE "/dev/modem"
#define ENDMINITERM 2 /* ctrl-b to quit miniterm */
#define _POSIX_SOURCE 1 /* POSIX compliant source */
#define FALSE 0
#define TRUE 1
volatile int STOP=FALSE;
void child_handler(int s)
{
STOP=TRUE;
}
main()
{
int fd,c;
struct termios oldtio,newtio,oldstdtio,newstdtio;
struct sigaction sa;
/*
Open modem device for reading and writing and not as controlling tty
because we don't want to get killed if linenoise sends CTRL-C.
*/
fd = open(MODEMDEVICE, O_RDWR | O_NOCTTY);
if (fd <0) {perror(MODEMDEVICE); exit(-1); }
tcgetattr(fd,&oldtio); /* save current modem settings */
/*
Set bps rate and hardware flow control and 8n1 (8bit,no parity,1 stopbit).
Also don't hangup automatically and ignore modem status.
Finally enable receiving characters.
*/
newtio.c_cflag = BAUDRATE | CRTSCTS | CS8 | CLOCAL | CREAD;
/*
Ignore bytes with parity errors and make terminal raw and dumb.
*/
newtio.c_iflag = IGNPAR;
/*
Raw output.
*/
newtio.c_oflag = 0;
/*
Don't echo characters because if you connect to a host it or your
modem will echo characters for you. Don't generate signals.
*/
newtio.c_lflag = 0;
/* blocking read until 1 char arrives */
newtio.c_cc[VMIN]=1;
newtio.c_cc[VTIME]=0;
/* now clean the modem line and activate the settings for modem */
tcflush(fd, TCIFLUSH);
tcsetattr(fd,TCSANOW,&newtio);
/*
Strange, but if you uncomment this command miniterm will not work
even if you stop canonical mode for stdout. This is a linux bug.
*/
tcsetattr(1,TCSANOW,&newtio); /* stdout settings like modem settings */
/* next stop echo and buffering for stdin */
tcgetattr(0,&oldstdtio);
tcgetattr(0,&newstdtio); /* get working stdtio */
newstdtio.c_lflag &= ~(ICANON | ECHO);
tcsetattr(0,TCSANOW,&newstdtio);
/* terminal settings done, now handle in/ouput */
switch (fork())
{
case 0: /* child */
/* user input */
close(1); /* stdout not needed */
for (c=getchar(); c!= ENDMINITERM ; c=getchar()) write(fd,&c,1);
tcsetattr(fd,TCSANOW,&oldtio); /* restore old modem setings */
tcsetattr(0,TCSANOW,&oldstdtio); /* restore old tty setings */
close(fd);
exit(0); /* will send a SIGCHLD to the parent */
break;
case -1:
perror("fork");
tcsetattr(fd,TCSANOW,&oldtio);
close(fd);
exit(-1);
default: /* parent */
close(0); /* stdin not needed */
sa.sa_handler = child_handler;
sa.sa_flags = 0;
sigaction(SIGCHLD,&sa,NULL); /* handle dying child */
while (STOP==FALSE) /* modem input handler */
{
read(fd,&c,1); /* modem */
write(1,&c,1); /* stdout */
}
wait(NULL); /* wait for child to die or it will become a zombie */
break;
}
}
--------
Thanks in advance,
George
|
|
|
|
|
George2 wrote:
I think the parent process should close fd and reset the properties of /dev/modem, and stdout, and close /dev/modem even if the clild process has done that.
It will need to close fd (which is /dev/modem), but I don't think (from memory) it needs to reset the properties of the devices. These properties are shared between processes, so the child doing this means that the parent does not have to.
Incidentally, Linux closes any file descriptors that the programs do not, so theoretically it does not have to close the file descriptor, but it's definitely good programming practice to do so.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Thanks, Ryan buddy!
You are a real expert!! 
George
|
|
|
|
|
Hi, all.
I'm now working with an Atl ActiveX control which displays various of shapes such as lines and circles.
GDI+ seems to be a good choice for drawing.
however,can GDI+ be used in ATL ?
I mean ,does anyone know where to put 'GdiplusStartup' and 'GdiplusShutdown'?
I've tried to put then in 'OnCreate' and 'OnDestroy' like this:
class ATL_NO_VTABLE Catlgdiptest :
public CComObjectRootEx<ccomsinglethreadmodel>,
...
{
...
public:
LRESULT OnCreate(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled)
{
// GdiPlus
GdiplusStartupInput gdiplusstartupinput;
GdiplusStartup (&m_gdiplustoken, &gdiplusstartupinput, NULL);
return 0;
}
LRESULT OnDestroy(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled)
{
// GdiPlus
GdiplusShutdown(m_gdiplustoken);
return 0;
}
HRESULT OnDraw(ATL_DRAWINFO& di)
{
RECT& rc = *(RECT*)di.prcBounds;
Rectangle(di.hdcDraw, rc.left, rc.top, rc.right, rc.bottom);
Graphics graphics(di.hdcDraw);
Pen pen(Color(255, 0, 0, 255));
graphics.DrawLine(&pen, rc.left, rc.top, rc.right, rc.bottom);
return S_OK;
}
...
};
But it doesn't work--the control draws nothing than a rectangle.
Is there any idea about it?
It's great to give any hint!
|
|
|
|
|
If we drug the toolbar of the main window and click any control on a toolbar,
normally focus is returned to main window after we release the mouse button
(at least is how Microsoft toolbars behave)
I am trying to implement a toolbar.
When to return focus to main window?
|
|
|
|
|
A simple way to answer your own question is, what bugs you the most when you use toolbars? I would prefer to have the focus returned to the main window as soon as a control on the toolbar has been used. That way I can continue working without that extra click required to move the focus to the working area. But then again, people have different preferences.
// Afterall, I realized that even my comment lines have bugs
When one cannot invent, one must at least improve (in bed).-My latest fortune cookie
|
|
|
|
|
WiB wrote:
This is programming forum.
Your answer is not a programmer's answer.
Your questions was "When to return focus to main window?"!!!
What kind of answer do you expect when you ask that question? On the other "How can I return the focus to the main window?" would have been a question that receives an answer with source code. Sorry, but with that kind of attitude you won't be getting any source code from me. I just wasted my time browsing through source code to find examples for you?! .
// Afterall, I realized that even my comment lines have bugs
When one cannot invent, one must at least improve (in bed).-My latest fortune cookie
|
|
|
|
|
Excuse me.
"...hasn't really been well accepted as far as the ratings tell us so far " - Nishant S
|
|
|
|
|
That's okay. No hard feelings. I get a bad temper sometimes.
// Afterall, I realized that even my comment lines have bugs
When one cannot invent, one must at least improve (in bed).-My latest fortune cookie
|
|
|
|
|
WiB wrote:
Your answer is not a programmer's answer.
Yes it is
Half of writing programs for people to use it to work out how they want a program to behave. This includes how toolbars work. Most people will want toolbars where the focus is returned to the main window as soon as the mouse button is released, as you said. You weren't very clear in what you wanted to know. It appears that you wanted to know the best time to return the focus to the window, so that is what the reply was. There was nothing wrong with the reply at all.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
