|
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"
|
|
|
|
|
WiB wrote:
Such answer could give any user that ever used floating toolbars
Of course it could. Your initial question sounded like you were wanting to do something different, which is why Toni answered as he did. You didn't ask which event to handle, so the answer wasn't given. You can't expect people to answer questions you don't ask.
WiB wrote:
I would like to know on which event I should return focus to main window?
WM_LBUTTONUP
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"
|
|
|
|
|
Thank you.
I couldn't understand why I couldn't catch this message.
It seems that for owned forms (as my floatimg toolbar) Windows set the mouse hook.
But I have got an idea.
Hope it will work.
"...hasn't really been well accepted as far as the ratings tell us so far " - Nishant S
|
|
|
|
|
Ryan, I took your previous advice (given a few days ago) on not to make things worse. Thank 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
|
|
|
|
|
Toni78 wrote:
I took your previous advice (given a few days ago) on not to make things worse. Thank you
You're welcome Glad to be of help
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"
|
|
|
|
|
I don't understand the process you describe, could you please specify?
When do you click on the control, after the drop? When the toolbar is floating? Is the control something like a combobox embedded on the toolbar?
WiB wrote:
I am trying to implement a toolbar.
Do you derivate a new class from CToolbar or directly from CWnd?
We do not inherit the Earth from our ancestors, we borrow it from our children - Antoine de Saint-Exupéry (1900-1944)
|
|
|
|
|
Ok.
Just to be sure on the words we use, let's define some:
When a toolbar is detached, we say it is "floating". When it is attached, we say it is "docked".
The behaviour of a toolbar when floating is different of when docked.
With the MFC, when a toolbar is floating, it is no more the direct descendant of the main window but the descendant of a new window, a docking frame. This new window is created when the toolbar is detached and is generally from the class CMiniFrameWnd. So, if you try to activate the parent, it might be not the good one.
IMHO, it should be the window receiving the command sent by the toolbar button which should set the focus to itself, and not the toolbar setting the focus to the window.
HTH,
We do not inherit the Earth from our ancestors, we borrow it from our children - Antoine de Saint-Exupéry (1900-1944)
|
|
|
|
|
The PostMessage method sends a message in an asynchronous way, and returns immediatly.
We do not inherit the Earth from our ancestors, we borrow it from our children - Antoine de Saint-Exupéry (1900-1944)
|
|
|
|
|
Another solution could be to store a pointer on the window which had previously the focus when the toolbar is activated, and then restore the focus to this window (if it still exists) after the processing of the command.
We do not inherit the Earth from our ancestors, we borrow it from our children - Antoine de Saint-Exupéry (1900-1944)
|
|
|
|
|
Consider the following background information:
a) I have a static library, say A.lib
b) I create a DLL, say D.dll, in which I write functions that require me to link the dll with A.lib
c) I ship my dll i.e. D.dll
Now comes my doubt:
Do I need to ship the static library (A.lib) also along with the DLL?
(I observed that when I use the dll in developing an application, the compiler gives me LNK2001 errors for all functions in the static library A.lib.
Of course, all LNK2001 errors disappear if I include A.lib in the application workspace. (But that's not the idea, I guess))
Any help will be greatly appreciated.
Richard
|
|
|
|
|
richiehere wrote:
Do I need to ship the static library (A.lib) also along with the DLL?
A.lib is required by the linker, so the users don't need it, and the application that you are distributing requires only the DLL file. Therefore, the answer is no, you don't need to ship the static library.
However, if you are distributing only your DLL (which is required by another programmer to develop his/her own code which places function calls to your DLL) then you need to distribute A.lib and A.h as well.
// 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
|
|
|
|
|
Thanks for the reply.
I was quite aware that while shipping the 'exe', I dont need to ship the lib file.
My specific query was regarding shipping of the static library while shipping the dll.
I thought the linker (while creating the dll) would automatically extract out the 'code' from the static library and insert it into the dll code. Therefore, not requiring the lib to be shipped alongwith the dll!
Please help.
|
|
|
|
|
Don't get upset richiehere.
In the previous post I mentioned the fact that if ship your dll only, then you need to send your lib and header file as well. Yes, the linker inserts the code into the dll but the dll is used by the application. For a developer it is necessary to know the functions and the parameters to these functions. That's why the header file needs to be shipped. On the other hand, the linker needs to know where to get the code (or resolve external dependencies) so that's why you need the lib file. But, you can also load the functions from a dll by calling LoadLibrary. In that case the lib file is not required. Having the lib file is more convinient. I don't understand why you won't ship your lib file, but it is up to you to decide what you want to do. If I had a choice I would prefer to get my hands on the lib file instead of calling LoadLibrary.
// 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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
