|
You can access them from Google.
|
|
|
|
|
Thanks, DavidCrow buddy!
George
|
|
|
|
|
You could start with http://leapster.org/linoleum/ (I admit, it's the second link when you type 'linux programming' in Google). Find some mailing lists to subscribe to, most development and support is on mailing lists and not on web-based boards in the Linux world (suggestion: get yourself a threading mail reader, like Mozilla Mail or even better, Mutt, it will greatly enhance your mailing list reading)
|
|
|
|
|
Thanks, roel_ buddy!
It is a very nice site!!
George
|
|
|
|
|
everybody knows what is the meaning of stdin, stdout, stderr, stdaux, and stdprm?
i just know those are standard input device, standard out device, and so on ...
but i don't have any idea(i don't understand) about standard input device, and its friends.
can somebody explain to me?
thousands thanx
>>when someone know more and more, they will feel they have weakness<<
|
|
|
|
|
They are io-streams that are opened by the runtime lib for you. Stdin is by connected to the console by default (but may be connected to some file with '<' on the command line.
Stdout is connected to to a console window on the screen by default, but can be redirected to a file with '>' on the command line.
Stderr is by default connected like stdin , but can not be redirected.
I hope this could help you a bit.
My opinions may have changed, but not the fact that I am right.
|
|
|
|
|
Those are just streams! just like any files streams, memory streams,...
You should find all the information you need in the MSDN library
A student knows little about a lot.
A professor knows a lot about little.
I know everything about nothing.
|
|
|
|
|
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
|
|
|
|
|