|
|
please help me i want read some of hardware serial ?
hamed
|
|
|
|
|
Have you considered the Win32_MotherboardDevice and Win32_DiskDrive WMI classes?
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Hello,
Is there any posibility in MFC/WinAPI to bring a parent dialog window for a modeless dialog on top of the modeless dialog ?
I've tried BringWindowToTop and SetWindowPos but the results are limited on activating the parent dialog only and not bringing it on top of the modeless one.
(I want to know if it is possible or not exactly the way that I specified. I know that it is possible if on the Create call for the modeless dialog I specify another window as parent and not the calling dialog.)
Many thanks in advance for any replies
|
|
|
|
|
to make the nextBuf and workBuf in the following code multi-thread save,
is it correct to replace "static" with "__declspec(thread)" in the code?
or it should be "__declspec(thread) static" ?
THANKS FOR THE HELP!
------
static int nextBuf ;
static char workBuf[8][64] ;
char * GetBuf()
{
nextBuf++ ;
if( nextBuf >= 8 ) nextBuf = 0 ;
return workBuf[nextBuf] ;
}
|
|
|
|
|
chenggong wrote: multi-thread save
I guess you meant "safe"? You did not specify your problem. So deducing your intent from your code it seems you are trying to share the workbuf[] array across threads? If so, you need to synchronize access to the GetBuf() function, not put the array into TLS as _declspec(thread) would do. Not to mention putting the array but not the indexer into TLS would certainly produce undesired behavior.
Also your design is, well less than [whatever]. Have you ever heard of the Singleton Design Pattern? Any Design Patterns?
Are you sure you should be writing multi-threading code?
|
|
|
|
|
The static just says that the variables are local to the module (.cpp file).
That is, they are not going to be directly used (by name) in any other module.
Both will work, but since you have already marked them as static i would keep that.
Also, you should init your global vars, even though in this case it still works without doing so.
Also, since the variables are (should be) only used in the function you may want to put them there.
i.e.
char* gb( void ) {
__declspec(thread) static int i = 0;
__declspec(thread) static char b[8][64];
if( i >= 8 ) i = 0;
return( b[i++] );
}
...cmk
Save the whales - collect the whole set
|
|
|
|
|
|
It seemed to me like this was a rather simple problem, but for some reason, I can't think up a good way to do this.
Say, I have class Base and class Derived : public Base. I also have a function that takes in a Derived pointer Func(Derived* derived) In my code, I have tried the following:
Base* bPtr = new Base();
Derived* dPtr = dynamic_cast<Derived*>(bPtr);
Func(dPtr);
Unfortunately, this is unsafe, which means that dPtr will always be NULL. Is the only way to do this one that involves using a self-implemented copy constructor that takes in Base* and copies all of the individual members? It seems to me that there must be another solution to something like this... (but I may very well be mistaken)
|
|
|
|
|
If you've only constructed a Base object it can't be a derived object.
The only way to have a Derived object is to create a Derived object (or a class derived from Derived).
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
|
|
|
|
|
Tell that to all the MFC developers that do things like:
CEdit *pEdit = (CEdit*)GetDlgItem( IDC_EDIT ); And think it is always a real CEdit object that they have on their hands! :P
Newbies: the above will only return a real <small>CEdit</small> pointer in a particular scenario. You only see it used so much because calling <small>CEdit</small>-specific methods works - they are wrappers for <small>SendMessage</small> and do not use any <small>CEdit</small>-specific data members, so you just happen to get away with it. But that does not make it right, and (IMHO) is a really bad habit to get into.
Peace!
--modified at 11:27 Thursday 16th August, 2007 - Mark's Suggestion
-=- James Please rate this message - let me know if I helped or not!<HR>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
Ooohh I forgot about that one. Yeah, you need to really know some internals of MFC
to do that 
Cheers,
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
You should switch the part of your post in small font to BIG font,
especially the "does not make it right...".
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Heh - done!
-=- James Please rate this message - let me know if I helped or not!<HR>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
I didn't look at MFC internals, but consider this scenario:
Base *pBase = new Child;
Child *pChild = (Child*)pBase;
What does the pChild refer to? I think a child, not a parent. (I didn't test it yet)
Now take a look at this:
CWnd* pWnd = new CEdit;
...
...
CEdit* pEdit = (CEdit*)GetDlgItem(EDIT_BX);
CWnd* GetDlgItem(UINT blah)
{
return pWnd;
}
if they did something like this, we actually have a pointer to a child.
// "Life is very short and is very fragile also." Yanni
while (I'm_alive)
{
cout<<"I love programming.";
}
|
|
|
|
|
In your first scenario, you will have a pointer to a "real" Child object.
In the first part of your second second scenario, pWnd points to a "real" CEdit. In the second part, the underlying object that pEdit refers to depends on what GetDlgItem(...) returns. In your example, it returns the pointer to a real CEdit, although through a CWnd pointer, and it is safe to cast that returned pointer back to a CEdit, because it WAS a CEdit in the first place. In the MFC code, it is a little different as shown below.
The only scenario where it will return a real CEdit object is if one is already in the handle map associated with the EDIT_BX edit control. For example, if you associate a CEdit class with the control using ClassWizard, and you then have it as a data member, then when you call GetDlgItem(...) with that control's identifier, you will get back a pointer to the existing CEdit data member.
If not, meaning that the HWND of the window you are looking for is not already in the handle map, you get back a pointer to a CTempWnd, which never was (and never will be) a CEdit. Additionally, that CTempWnd instance gets destroyed the next time the message pump starts running, which is why the docs say that the returned pointer may be temporary and should not be stored.
Peace!
-=- James Please rate this message - let me know if I helped or not!<HR>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
James R. Twine wrote: you get back a pointer to a CTempWnd
So bad. Thanks for the information. From now on, I'll avoid using GetDlgItem. What I see here is really a bad coding style, I think. Finding a window, creating a temp one, and destroying that, is not what I like to happen, when I just need to enable or disable(, etc.) it( Considering the fact that I try this for a lot of controls at the same time.)
Thank you, really informative.
-- modified at 13:32 Thursday 16th August, 2007
// "Life is very short and is very fragile also." Yanni
while (I'm_alive)
{
cout<<"I love programming.";
}
|
|
|
|
|
Mark Salsbery wrote: If you've only constructed a Base object it can't be a derived object.
The only way to have a Derived object is to create a Derived object (or a class derived from Derived).
Downcast is OK.
Maxwell Chen
|
|
|
|
|
Of course it is - if the object is actually the type you're downcasting to 
It was not in the OP's example.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Mark, If the derived class does not define any data members then the structure is not changed and therefore the base class can "be" a derived class although you would have to use old style cast or reinterpret_cast as the others are intended to report this as an error. So not saying it's a good idea. Also in most cases the need to up-cast is indicative of a poor design. However when dealing with a library...
|
|
|
|
|
Fine. I guess "can't" was the wrong word.
IMO it's a really bad idea. It requires knowledge of the class one really shouldn't
need to have to know. Plus it makes future additions to the derived class
problematic.
Why would one derive a class and not add anything? Even a virtual function
override is going to add to the class.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark Salsbery wrote: IMO it's a really bad idea.
Yes, as I stated. I have used it to deal with MFC issues in the past. I have never designed it into my own classes.
Mark Salsbery wrote: Why would one derive a class and not add anything? Even a virtual function
override is going to add to the class.
Notice that the virtual override does NOT work (goes to foo) making this a very tenuous situation, but under certain conditions...
class foo
{
int n;
public:
foo(int v){n=v;}
virtual void dump(){cout << "foo: " << n << endl; }
};
class bar : public foo
{
public:
virtual void dump(){cout << "bar: "; dump();}
void dumpex(){cout << "bar: "; dump();}
};
foo* f = new foo(12);
bar* mybar = reinterpret_cast<bar*>(f);
mybar->dump();
mybar->dumpex();
|
|
|
|
|
I'm not disagreeing at all. It just makes me cry a little inside
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark Salsbery wrote: It just makes me cry a little inside
Nah, it's all good. I'm working on some C# I developed last week as we speak. I just noticed some Rube Goldberg stuff I wrote, did a   and quickly leveraged the delete key.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
