|
modal dialogs come when user selects an item from the menu.
www.logicsims.ir
|
|
|
|
|
And by definition, modal dialogs must be dismissed before you can interact with any windows behind them.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
I know, but I must do this for our project,
There must be a way to do something like this.
www.logicsims.ir
|
|
|
|
|
You can always create the modeless dialog via it's own UI thread. The issue is the modal dialog is preventing pumping of your messages.
onwards and upwards...
|
|
|
|
|
thanks.
Do you mean that I must create create a thread and then craeting the modeless dialog from that?
www.logicsims.ir
|
|
|
|
|
Hi There ,
I am stuck with this problem since weeks. Apparently I am new to Visual Studio. I have a client dll which exposes some APIs . I am supposed to create a C++ Unit Test project in Visual Studio 2005 and test the methods in the dll. Unfortunately I am not able to invoke the methods , I often get linking errors such as
"error lnk2031: unable to generate p/invoke for"
The .h file has some function exports .I am pasting part of the .h file here
//.h file starts
#ifdef ITMENTITLEMENTWRAPPER_EXPORTS
#define ITMENTITLEMENTWRAPPER_API __declspec(dllexport)
#else
#define ITMENTITLEMENTWRAPPER_API __declspec(dllimport)
#endif
// This class is exported from the itmEntitlementWrapper.dll
class ITMENTITLEMENTWRAPPER_API CitmEntitlementWrapper {
public:
CitmEntitlementWrapper(void);
// TODO: add your methods here.
};
extern ITMENTITLEMENTWRAPPER_API int nitmEntitlementWrapper;
ITMENTITLEMENTWRAPPER_API EINSTALLTYPE fnGetInstallType(const wchar_t * InstallType);
ITMENTITLEMENTWRAPPER_API int vm_wstrcmp(const wchar_t* s1, const wchar_t* s2);
extern "C"
{
/**
* fnitmEntitlementWrapper_ENTITLE_INST_FIRST - The purpose of this method is to load the caEntitlement.dll*/
ITMENTITLEMENTWRAPPER_API BOOL fnitmEntitlementWrapper_ENTITLE_INST_FIRST(const wchar_t *eProductID = L"eProductNone",
const wchar_t *ePackageID = L"ePackageNone", HWND hWndParent = NULL);
//.h file ends
How am I supposed to call these methods in UnitTest.cpp. I am adding a dll reference to the Testing project and also tried to use DLLimport . Can anyone please help.
Thanks
Diya
|
|
|
|
|
See the suggestion here[^].
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
I first saw this technique in the stl where collections return
std::pair<iterator, bool> from their insert method. The bool indicating if the item was inserted or already existed.
Personally I dislike this, I find the names first and second which identify the pair's elements very misleading and find I'm constantly having to look at doco to see what something is. The worst case I've seen was along the lines of
pair<bool, pair<bool, bool> . How could anyone be expected to remember what result.second.first is?
I prefer to pass in a reference to a variable
eg
iterator map::insert(iterator position, const value_type& x, bool& wasAdded)
This has the disadvantage that the caller has to allocate a bool and pass it in even if they're not interested in the result (this can be overcome by using a pointer with default value of NULL but that's also ugly)
I blame python and its tuples for this outrage. What do others think?
|
|
|
|
|
Well, as long as we're talking about personal preferences.
I think that templates, in general, has uglied up the language by spraying < and > all over the place. I think somebody went nuts with this stuff and talked the language committee into using it. Plus the fact that it's not just the template definition that's affected but the coder has to use that syntax when referencing it had contributed to the unreadability of code.
I mean > is already used in pointer use (->) and in inequality tests (greater than) and then there's the right shift (>>) operator. Then somebody comes along to overload it for "cin" and other stream io. And don't get me started on <
I mean really, try writing code that takes some template result as a pointer to an object that you want to stream data into. Count the >'s. If they were right parens ) instead, it would remind me of early Lisp.
|
|
|
|
|
Chuck O'Toole wrote:
I think that templates, in general, has uglied up the language by
spraying < and > all over the place.
True, C++ is now almost unreadable due to templates.
==============================
Nothing to say.
|
|
|
|
|
That's c for you though.'&' is similarly overused.
pair<int, pair<int, int>>
confuses most compilers, you need
pair<int, pair<int, int> >
|
|
|
|
|
typedef pair<int, int> IntPair;
typedef pait<int, IntPair> IntIntPair;
Won't this makes your life simpler?
|
|
|
|
|
Yeah, I always thought the same about templates... make everything hard to read.
|
|
|
|
|
_Josh_ wrote: What do others think?
Rich syntax has nothing to do with maintainable code.
"Clever" coding tricks demonstrates that one has mastered a language while at the same time demonstrating that one hasn't mastered software development (which of course includes much more than just producing code.0
|
|
|
|
|
I have a colleague working with me at the moment and he loves to do this (NULL first) and I hate it.
Has anyone actually ever been saved from putting a bug into production because this construct has saved them from missing an '='?
Is there any other reason to do it?
|
|
|
|
|
Yes, it has saved me.
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
Oh, I'm sure it saved somebody some debugging time. "saved" is a bit of a stretch unless somebody would have released something with insufficient testing. And if they do that, there'd be plenty of other bugs that will bite them due to the lack of testing.
Personally, I hate it too. I tend to read code like English, left to right, and reading it as "if my pointer is null" is more natural for me than the other way around. Speakers of other native languages may find the other order more natural.
In my opinion, if you are writing code that will be maintained by someone else, a support team or other engineers as you move on to bigger projects, then "readability" is more important. Readability include code structure / indents, comments (meaningful), reasonablly neumonic variable and function nammes, and making if statements readable as they convey the "branching logic" of the program.
|
|
|
|
|
This has helped me detect the problem, but I cannot say that it would've gone into production code because it would surely be detected during testing.
But nevertheless, it was a good trick to detect the typo.
However, it was not fool proof because sometimes we would need to compare 2 variables instead of a variable and a constant.
In such cases a single equal sign would make the assignment and you would get unexpected results.
Having said all this, I don't think it is necessary to write the constant first anymore with the current compilers because it would surely give you a warning.
For example, VS 2010 shows the C4706 warning.
I'm not sure about other compilers like GCC.
|
|
|
|
|
«_Superman_» wrote: For example, VS 2010 shows the C4706 warning.
Yes, that is in fact a very good alternative, specifically if you set warnings=errors for production code. At the time I started using the practice there were no such warnings, and thus no such elegant alternative. Also I remember quite a few typical constructs that deliberately used assignments, such as
if ( errorcode = foo() ) {
}
Fortunately I don't see that kind of code so often anymore, making this warning a perfectly reasonable and useful alternative.
|
|
|
|
|
Even I love this. 
Putting constant at left hand side surely saves from missing '='. The earlier compilers were not intelligent to raise a warning like the latest ones. That might have forced people like me to cultivate this habit. Otherwise one had to debug code to find such kind of bug (Some great minds might have found these kind of bugs with their open eyes, I won't deny that as well). But surely it wont give u a chance to debug the code to find such bugs. That's my personal opinion.
|
|
|
|
|
looks like you are new to programming? Not sure, but when I was a fresher I used to hate my colleague writing
if(bCondition)
andI purposefully wrote my lines as
if(bCondition==TRUE)
Then I realized I'm stupid if I followed my "spoken" code way.
So, in short it's the correct form to keep the constant on the left. Don't do the other way and don't hate your colleague 
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy.
|
|
|
|
|
Ha, I have the opposite problem.
If the variable is decleared to be bool (C++) or BOOL (C/Microsoft) then I don't mind the if (bCondition) or even if (!bCondition). What kills me is if the variable is an int or similar and that short cut is used just because it evaluates to a zero/non-zero test. Damnit, write:
if (iVar != 0) or
if (iVAR == 0) if that's what you're testing for and don't use the "boolean variable" if notation.
if (!iVar) to mean "if iVar is equal to zero" just drives me crazy.
|
|
|
|
|
Chuck O'Toole wrote:
if (!iVar)
to mean "if iVar is equal to zero" just drives me crazy.
I second that.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
Thirded. 
|
|
|
|
|
Yup I hate that too!
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)