|
How to get the nearest NameServer programatocally. I tried to broadcase a message on port 53 using 255.255.255.255 as IP. No response . Why ?
Anita Eugene
|
|
|
|
|
I tried to have a common variable which would be modified by more than one function of an interface in COM.
But I found that any modification on the variable by one function was not reflected in the other function.
Why is it so?
Is there any way of having a common variable?
Thank You.
Yamuna.E.
Yamuna.E.
|
|
|
|
|
I tried to have a common variable which would be modified by more than one function of an interface in COM.
But I found that any modification on the variable by one function was not reflected in the other function.
Why is it so?
Is there any way of having a common variable?
Thank You.
Yamuna.E.
Yamuna.E.
|
|
|
|
|
I tried to have a common variable which would be modified by more than one function of an interface in COM.
But I found that any modification on the variable by one function was not reflected in the other function.
Why is it so?
Is there any way of having a common variable?
Thank You.
Yamuna.E.
Yamuna.E.
|
|
|
|
|
Are you trying to use the COM interfaces from multiple programs? If so, the problem is that each COM object is created seperately for each program (usually). If you're talking about the same program, then it could be Thread Local Storage issue.
A single object will generally share it's data between the interface functions.
|
|
|
|
|
Hi,
I am trying to use the COM interface from multiple programs as you said.Is there any way in this case to have a common variable?
THANK YOU.
Yamuna.E.
|
|
|
|
|
Hi,
I am trying to use the COM interface from multiple programs as you said.Is there any way in this case to have a common variable?
THANK YOU.
Yamuna.E.
|
|
|
|
|
We have developed an Acive X in VC++ and the graphical interface in VB.
We would like to debug both applications at the same time to see how they interact with each other. How can we do it?
There is no problem to debug 2 VC++ applications but not 2 apps from different developing environments.
Thanks in advance 
|
|
|
|
|
|
How do you display a menu for a CPropertySheet?
|
|
|
|
|
In my dialog-based application I use some other (modeless) dialogs-boxes
that have the same size than my parent and aligning exactly centered in
my frame-dialog when appearing. ( created with MyDialog->Create() ).
For this behavior I had to use the style 'Child' in the dialog-editor.
For some reason I need one dialog to appear MODAL and so I created the dialog with
MyDialog->DoModal(). If I leave the style 'Child' the dialog totally locks the application
when appearing. So I changed the style to 'Popup'... Now it worked ALMOST like a charm.
One problem left:
When I open the modal dialog it is exactly aligned relative to its parent window.
When I move the parent dialog but still visible on the screen and then open the
modal dialog it also aligns correctly.
But from the moment I move my parent out of the screen so that e.g. only a part of
my parent is visible the modal dialog appears fully visible docked to the edge of
the screen but not aligned to the parent anymore.
Is there any workaround or setting that the modal dialog appears aligned to my parent
even if I move my parent out of the visible part of the screen.
As I created all my dialogs in the application with thin borders and no title-bar
you do never realize that with every view-change a new dialog is created.
Only in the above mentioned situation the thin boarderd-modal-dialog stands alone on
the screen - looking ugly...
Any Ideas on that ?
Manfred
---
'Programming is knowing...'
|
|
|
|
|
> Is there any workaround or setting that the modal dialog appears aligned to my parent
> even if I move my parent out of the visible part of the screen.
How about obtaining the geometry of your parent window when processing WM_INITDIALOG, and use SetWindowPos() or similar on the modal dialog to the coreect location?
Peace!
-=- James.
|
|
|
|
|
> Is there any workaround or setting that the modal dialog appears aligned to my parent
> even if I move my parent out of the visible part of the screen.
How about obtaining the geometry of your parent window when processing WM_INITDIALOG, and use SetWindowPos() or similar on the modal dialog to the coreect location?
Peace!
-=- James.
|
|
|
|
|
> Is there any workaround or setting that the modal dialog appears aligned to my parent
> even if I move my parent out of the visible part of the screen.
How about obtaining the geometry of your parent window when processing WM_INITDIALOG, and use SetWindowPos() or similar on the modal dialog to the coreect location?
Peace!
-=- James.
|
|
|
|
|
<<< In the name of GOD >>>
Hi.
I want to buy 8 MB graphic card.
Please write your comment about it ...
Trident, ATI, ASOOZ, ... ?!!!
Hadi Rezaie
|
|
|
|
|
AAAARRRRGGGHHHH !!!! All those cards suck. 8 MB cards suck. You need minimum 16 MB if you want to do anything 3D, try brands like nVidia, Voodoo3, Matrox.
Of course, if you have a 386 or something, buy an S3 by all means. I guess you need to also say what you want to do with it...
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
<<< In the name of GOD >>>
Hi.
Please write example about using operator in class.
for example: operator = or operator <= or ...
Hadi Rezaie
|
|
|
|
|
An example snippet from my CString replacement
class CGString
{
public:
CGString();
CGString(const char * pChar);
CGString(const CGString& str);
CGString(const double);
virtual ~CGString();
// Operators
operator const char*();
CGString& operator=(const char*);
CGString& operator=(CGString);
CGString& operator=(const double);
etc, etc.
CGString::operator const char* ()
{
return m_string.c_str();
}
CGString& CGString::operator=(const char *s)
{
m_string.assign(s);
return *this;
}
CGString& CGString::operator+=(const char*c)
{
m_string.append(c);
return *this;
}
m_string is a string from the standard library - the idea was to write a class that didn't need MFC but would use the CString syntax so that changing code from MFC to Win32 would be less painful.
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
On thing to watch out for in your string replacement class is variadic parameters.
There is no type to a variadic parameter (...), so it doesn't cause the conversion operator to be called (operator const char*()), so if you pass your CString replacement to a function like printf, it will instead blindly try to treat your class like whatever type you specified.
This isn't a problem for CString, because CString's first data member is the actual internal char *, but for you, the first member will actually be the vtable of your virtual destructor, causing the printf to produce garbage.
|
|
|
|
|
Thanks for telling me this - although it is unlikely I would have passed a string as a parameter to printf, I am interested from the POV of good design. I initially wanted to derive from the standard string, but found out it does not have a virtual destructor. Looking through Stroustrup I found that this was intentional and the idea was to make a string class ( for example ) by having a string as a member variable and accessing it that way. The question is, given that this was an intentional design decision on the part of the language architects, what options would I have to work around this ?
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
Yes, you're correct that the standard committe deliberately chose to exclude a virtual destructor, as did the MFC development team.
The MFC team did it spcifically to allow CStrings to be passed as parameters to functions like printf. They also do some nasty behind the scenes memory allocation. They actually store the length of the string and reference count information as a negative offset of the string data pointer. All this just to make variadic and similar functions work correctly with CString.
Your choices are pretty limited. You could inherit from std::string privately, or you could just use it as a member like you are. However, I would suggest against using a virtual destructor unless you plan on letting people derive from it. Likewise, I would advise against virtual functions, since virtuals add a vtable pointer.
To be honest, I'd rather just rewrite the code to use std::string natively rather than make it pretend to be a CString.
|
|
|
|
|
<<< In the name of GOD >>>
Hi.
What is different between CFile and CArchive for write and read from file ?
Hadi Rezaie
|
|
|
|
|
CFile just provides basic read and write operations. CArchive uses a CFile to add serialization capaibility to MFC and to use the inserter/extractor operators (<< and >>)
|
|
|
|
|
<<< In the name of GOD >>>
Hi.
Please explain to me rules about put names for variables.
Understand ?!!!
Hadi Rezaie
|
|
|
|
|
You mean Hungarian notation ? Basically the standard way of doing things is to preface a member variable with m_, a global ( globals are evil though, so you have none, right ??? ) with g_ and then the first letter or two tell you the type of the variable.
i.e.
int m_iMyInteger;
CString m_szMyString;
But ultimately, these rules only benefit if a team all follow them - in other words, if you work alone, what convention you use is up to you.
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
