|
Oscar K. wrote: //MYDLL_EXPORTS is set in C++\Preprocessor
What do you mean by that? MYDLL_EXPORTS should only be defined in MyDll.cpp, just before the #include "MyDll.h". You also need to ensure that you add MyDll.lib to the linker options in your build.
[edit]
On reflection I think maybe the definition of extern PrintDelegate printDlgt; is not correct. I think it should also by declared with MYDLL_API.
I will try and test this later today.
[/edit]
modified 17-Mar-24 5:19am.
|
|
|
|
|
#define MYDLL_EXPORTS is already set in Debug\Properties\C++\Preprocessor
#define MYDLL_EXPORTS in MyDll.cpp invokes macro redefinition
extern PrintDelegate printDlgt in MyDll.h is usual decision, that's how it's done
|
|
|
|
|
Oscar K. wrote: #define MYDLL_EXPORTS in MyDll.cpp invokes macro redefinition
You should only have it in one place, and inside the dll implementation file (MyDll.cpp) is the better choice.
Oscar K. wrote: extern PrintDelegate printDlgt in MyDll.h is usual decision, that's how it's done
Correct, but that only makes it visible to the build of the DLL. When you build your test code the it is declared extern which the compiler accepts as it should be defined in another compilation unit, as part of the build of the main program. But when you try to link the program the linker cannot find where that item is actually defined because it only exists in the DLL. And since it has not been exported it is not listed in the lib or exp files.
|
|
|
|
|
I added extern PrintDelegate NS::printDlgt; to TestDll2.cpp, but I have got again error unresolved external. I see class A (MyDll.dll) in Dll viewer.
|
|
|
|
|
And you will continue to get that error until you create the object inside the namespace and use the MYDLL_API export prefix. As I have said more than once, you cannot use extern on an item that only exists in a DLL.
|
|
|
|
|
I changed extern PrintDelegate printDlgt;
to
extern MYDLL_API PrintDelegate printDlgt;
Now it works properly
Thanks Richard
|
|
|
|
|
Hi,
How can I get zonal id like "America/New_York" in c++?
|
|
|
|
|
|
no, this will return result in DWORD, I am looking for zone name in a string.
|
|
|
|
|
|
I am facing some problems to install the java compiler. actually in my knowledge I have installed the java compiler and also edited the enviorment variables on my pc.
PS E:\java> gcc main.java
gcc.exe: error: main.java: Java compiler not installed on this system
PS E:\java>
|
|
|
|
|
Perhaps, the Java Discussion Boards[^] would be a better place for this.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
Anyway, as far as I know. The java compiler is called javac. Hence, the correct command line should be:
javac main.java
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
You are right. Thanks Bro
|
|
|
|
|
And you are welcome!
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
My secondary windows (output, find results, ... ) are all misplaced.
For example, when I do a search in files and I click on a result, instead of showing the code window in a new tab next to my other source code windows; it opens up a tab in the search window.
(if it makes sense)
Any Ideas ?
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
What version of VS?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
The latest (not preview version)
It looks like the windows are all tools windows or all are not tools windows.
alt-tab cycles between all of them.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
I thought there was an option in Tools/Options to reset the window layout.
If that doesn't work, you can do a Repair from the VS Installer, and that will surely set everything back to the way it was out of the box.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Try Tools/Customize; down should drop the list of (most unticked) options for the interface look. Mine's defaulted at "standard", the only ticked box. But there's a hayrick-load of other untested to toss your implements into and have a go.
(have not tried this suggestion ... too timid a developer I'm afraid)
|
|
|
|
|
This is an observation rather than a question - if it's not appropriate I will happily delete it.
I was wondering what would happen if multiple calls were made to SentNotifyMessage() (where the receiving window is owned by a different thread) during the period that the receiving thread was still processing the first such message it received. My guess as that the thread would be deemed hung and that SendNotifyMessage() would fail. Wrong!
The documentation says "...If the window was created by a different thread, SendNotifyMessage passes the message to the window procedure and returns immediately; it does not wait for the window procedure to finish processing the message."
Saying that it "passes the message" I think makes it clear that the message doesn't go into the same queue as messages posted with PostMessage().
I set up an experiment (on Windows 10) where the thread which owns the window 'hangs' itself (simply by sitting in a tight loop waiting for a period time to expire) for a substantial period of time when it first receives a message. The thread which sends the messages sits in a loop continuously sending a large number of messages (using SendMessageNotify). Using TRACE output to monitor what was happening I could see that all of the calls to SendMessageNotify() succeeded and happened whilst the receiver was hung processing the the first message. When that hung period expired it then received all of the remaining sent messages in succession. This worked with 100,000 "queued" messages. I was surprised. Windows obviously queues these messages and can cope with a very large number of them.
|
|
|
|
|
|
Agreed, it's not something I would rely on. I was just intrigued to discover that there is some sort of undocumented queue for sent (as opposed to posted) messages.
|
|
|
|
|
If I call SendMessageTimeout() with the flag SMTO_ABORTIFHUNG and a finite timeout period then it could fail (return 0) due to either of these reasons:
1. Timeout (the thread which owns the window started processing the message but didn't complete it within the timeout period).
2. The thread which owns the window was considered to be hung, so didn't (and won't) process the message.
In the first case GetLastError() returns ERROR_TIMEOUT (1460). I can't find any error codes in winerror.h which look relevant to the second case (hung thread).
What I actually want to know, immediately after SendMessageTimeout() returns, is whether the thread which owns the window has or will actually start processing the message. I don't need nor want to wait until it has finished processing the message.
I've spent a couple of hours searching the web and reading various articles, questions etc. but not found an answer to this.
A little while later... I've set up a test case where the window owning thread is spinning in a loop, and then I call SendMessageTimeout(hWnd, WM_MY_MESSAGE, wParam, lParam, SMTO_NORMAL|SMTO_ABORTIFHUNG, 1000, &dwResult).
SendMessageTimeout() immediately returns 0 as expected, and calling GetLastError() returns [drumroll...] 18 (ERROR_NO_MORE_FILES)!!! Go figure...
So it seems there are 2 yucky ways to trap this:
1) Wrap a timer around the call to SendMessageTimeout(), and if it returns in less than the timeout period (1000ms in the example above) then we know it failed because the thread is hung.
2) Test GetLastError(), if it's ERROR_TIMEOUT then we know it's a timeout, if it's ERROR_NO_MORE_FILES then we assume it's because the thread is hung. Or maybe if it's NOT ERROR_TIMEOUT then assume it's because the thread is hung.
Method 1 is smells of kludge, method 2 relies on undocumented behaviour.
And while we are on undocumented behaviour, it seems that passing a timeout value of 0 means "infinite timeout" although no doc I can find for SendMessageTimeout() mentions that.
And some time later again... Well the behaviour is inconsistent. I've also had it fail (return 0) immediately with ERROR_TIMEOUT, and bizarrely sometimes fail immediately with error code 0 (ERROR_SUCCESS). This is Windows 10. It seems that all bets are off in trying to interpret the return value and/or error code.
modified 12-Mar-24 8:27am.
|
|
|
|
|
I would suggest that you raise this on one of the Microsoft support forums, as it will then get through (in time) to the people responsible.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
