Comments by PaulowniaK (Top 39 by date)

Yes, I do have access to the type library.

OK, second edit...

Opening the "correct"(!!!) DLL using the correct procedure in OLE Viewer results in what resembles the IDL file very closely to be displayed.

The COMs are all developed in-house and I have source codes to them, but I can't disclose any part of it, I hope you understand...

Also there is far too much of it for me to understand them all, so frankly, they are all black boxes, except that I have had a go poking around the project settings and the IDL file.

Sort of.

The break point marker on the left ledger doesn't turn red. Something about the symbol not being loaded.

So the debugger doesn't stop.

Neither can I, and that's why I'm here! :-) Seriously, even if I start multiple VS instances, I can only attach one of those at a time to the application so I can only debug one project at a time.

I may be getting it very wrong, but they are all on my PC already...?

Er... if that worked, I won't be asking the question.

The problem is that I can't debug in proxy nor SV, and I'd love to know why not!

I can attach each of my projects (proxy, client and server) separately to the application, but I don't think I can do more than one at a time as they are in different solutions.

When I attach to the client, I can stop at the designated break point. Proxy and Server say they are not loaded when I attach them.

>So the steps are convert local time to UTC - store it - read it back and convert to local time.

There's the problem.
I want to convert local time to UTC, store and read it back as UTC.

>you have a bug

You don't say!

Thanks, but it's the other way around.

I found a way to write out in UTC. I need a way to read UTC back into the program and keep it UTC.

Yes, I fully agree with you.

The problem I need to solve is that I don't seem to have full control of whether to convert to local time or not.

Thanks for your suggestion. I agree with you, but I prefer to store the time as string so that service personnel can read the file in a text editor and make service related decisions. If the file is written in UTC then we will need a separate application for the service personnel.

Actually, I am well aware that writing the file in local time is stupid. If the PC containing the program travels half way around the earth and the PC clock is set to local time, who knows what'll happen when the program next runs.

What I'd really like to do is to write out the UTC in human readable form, then read it back in as UTC without applying any conversion. Is that possible?

I think I'm with you...

Although, in this case, it's a "first party DLL" if there is such a word...

Umm.. that's not entirely true... The DLLs are where they were designed to go.
What the original SE didn't know about is where my test App will live. Don't know if that changes anything though...?

Thanks for the suggestion.
I hadn't thought about DLLMain till now.
It appears there isn't an explicit DLLMain (unless I'm looking for it in the wrong place), so that could cause LoadLibrary to return FALSE.

However, in that case, how would you explain the fact that LoadLibrary works when I
1) copy the EXE to the DLL directory or
2) copy the DLL and all the dependencies to the EXE directory?

(Please also see my replies to other contributors above.)

Thanks for the suggestion.
I had used Dependency Walker a few times in this investigation.

While the DLL in question was in its original location, the only things the Dependency Walker complains about are MSJava and MSVCR80D, which I believe is not a big deal.

Also, from what I've observed, I don't think it's a matter of missing dependencies. If that was the case, I shouldn't be able to load the DLL even when I copy the EXE to the DLL directory.

(Please see my reply to Satheesh1546 above as well.)

Thanks for your suggestion.
I copied the DLL in question to my EXE directory.
Then checked it using the Dependency Walker (as suggested by Lakamraju Raghuram below) and worked out the missing DLLs.
I copied all the DLLs listed as missing in the Dependency Walker to the EXE directory.
I made sure there were no more missing DLLs identified by the Dependency Walker (except for MSJava and MSVCR80D).
And guess what, it worked!
What I don't get is, I copied over all the necessary DLLs from the same place. It's not like there were any DLLs missing in the first place...???

Thanks for your comment, but you may wish to look up the phrase "rhetorical question"...

Anyway...

LoadLibrary returns an empty handle.
Subsequent GetLastError returns 0x7e which means the module is not found.

I have had multiple people check the path and it's correct.
Can't quite see access rites being a problem (especially as I'm on XP).

Still stuck...

OK, thanks for the suggestion. I shall migrate to the appropriate forum.

As I've written in my original post, I have found a lot of help. Just that as far as I'm concerned, they don't start at the beginning enough. There seems to be one vital piece missing, from when a solution is created to when a template is written.

Thanks, but maybe I didn't explain well enough. The biggest problem is that what's writing the log is a 3rd party software which I have no control over its internal doings. I'm stuck with the reality that I get 10s and 100s of MB of log.

Thanks!

Works now.

I updated the question to show what's inside CMyDataItem.

I can't see what could be causing the problem except for maybe the CStrings.

Thanks for your suggestion.
All I can say is that the usage I've shown is how we use CSingleLock in my workplace and it's been demonstrated to work fine in the past.

Also, commenting out the line does not help solve the problem I've observed.

(To test things a little by little, I've only used a single thread tester so commenting out the CSingleLock stuff doesn't cause any problems for the moment.)

Yup.

That bit seems OK.

It turns out, the copy memory bit is going wrong, but can't think why...

Nope. The library is getting loaded as part of an initialization process of my DLL, but it's not directly at the entry point.

Thanks.

Firstly, whether my DLL gets wiped and rebuilt depends on the usage of the application. The path that it goes through in getting rebuilt is essentially the same as a full shut down followed by a full start up. So I wouldn't know when to keep the DLLs alive and when to get rid of them.

As for the descendant DLLs, I may be wrong about them. I just created a dummy project that loads and unloads ThirdPart.dll in succession. No problem there, so the descendants are just not being written to the output window.

Thought continues... ... ...

Of course I used a debugger! ;)
I wrote out the DataTerms.S_ROOT_END to a separate string to check the content. That works fine. It just refuses to be added to the end of m_strData. I can check strData in the text viewer of the debugger but it won't show in the XML viewer (obviously).

Here is my original attempt:

string strData = DataTerms.S_ROOT + m_strData + DataTerms.S_ROOT_END;
XmlDocument dataDoc = new XmlDocument();
dataDoc.LoadXml(strData);

Of course the mention of "luck" is just a figure of speech... Anyway, the point is that it only has 1 DOM node, so yes, I am doing what I mean to do. I know this because if I write the entire string as I want it to appear directly in the code the XML Load() function works. It just fails if I build up the intended XML string within the code.

Thanks.
I tried it, but still no luck. :(
Only the starting tag gets added.

The original question turned up a bit wrong, but the actual attempt looks pretty much like this suggestion.