C / C++ / MFC

Re: Excel Automation error.

3-Mar-09 2:47

You could set up the Excel file as an ODBC data source and then use standard database functionality to connect that to your grid?

As for getting notifications of changes...not sure about that.

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

Excel Automation error.

SRKSHOME2-Mar-09 23:23

SRKSHOME

2-Mar-09 23:23

Hi all,
I am trying to add excel add-ins programmatically through C++ code.
It is srunning fine on xp or lower OS. But it is giving an 'Unhandled exception' on Vista.

m_xlAddins = xl.GetAddIns();
if(xl.GetVersion()=="12.0") //if it is office 2007 then only install it.
{
m_xlAddin = m_xlAddins.Add(strAddin,covTrue);
m_xlAddin.SetInstalled(TRUE); //---> giving an error on vista.
}

Could anyone help me please?

David Crow3-Mar-09 3:08

David Crow

3-Mar-09 3:08

SRKSHOME wrote:
m_xlAddin.SetInstalled(TRUE); //---> giving an error on vista.

Could this be attempting to write to a location on the disk or in the registry for which it does not have sufficient privileges?

"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown

"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

Synchronizing fstream - Need suggestions/ideas

PankajB2-Mar-09 22:20

PankajB

2-Mar-09 22:20

Hi there.

I have created a dll(text based logger) that can be used to create a text based log.

Now, my problem is, let's say, this component is being used by several other components and those several components are logging into the same text file. Now, that’s a problem...Synchronizing problem.

Need suggestions to resolve this problem.
Any work around will be appreciated.

Thanks
PanB

Stuart Dootson2-Mar-09 22:47

2-Mar-09 22:47

Single-threaded - terminate every stream output operation with std::endl to properly flush the stream before the next stream operation.

Multi-threaded - you could use a critical section to serialize use of the log file - something like:

std::ofstream logFile;
CRITICAL_SECTION csLogFile;

   :   :   :   :   :   :

EnterCriticalSection(&csLogFile);
logFile << stuff << std::endl;
LeaveCriticalSection(&csLogFile);

Alternatively, put all the logging information in one thread and send messages to that thread to log (you could share a queue of strings between threads and have a synchronised function that enqueued a log message?)

Multiple processes? - you could do something with file locking? But not with vanilla C++ - you'll need some OS specific functionality. And even then, I wouldn't guarantee it working on network drives.

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

PankajB2-Mar-09 23:05

PankajB

2-Mar-09 23:05

Stuart my requirement is implement synchronisation across network. On the basis of your exp. what's your suggestion? Give me just a pointer, after that i will dig the concept Smile | :)

Stuart Dootson2-Mar-09 23:21

2-Mar-09 23:21

PankajB wrote:
implement synchronisation across network

Multiple machines?

If that's the case, I'd be tempted to use RPC or some TCP/IP service, so you have a single point of contact for logging.

File-locking is not (I seem to remember) particularly recommended for files on a network server, so I'd really be tempted to use a client-server mechanism.

The easiest way would be to have a very primitive web server on a machine (you can implement one in a few hundred lines of code[^] - that one's Unix specific, but (from experience) I know you can reuse 95% of the code on Windows) that, when you POSTed a message to a particular URL, would write that message to the log-file.

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

PankajB2-Mar-09 23:33

PankajB

2-Mar-09 23:33

A straight questions – By any mean, can we open any file in exclusive lock mode.
I mean, if I open a file, it will be locked automatically and then, in case any other process try to use the same file, the process can get that state.

What I am planning is, in case I can find that the file is locked, I will create a temp file and write my log into in that file. And my logger will be intelligent enough to find whether any temp files exists and if they do, then it will copy the content to the mail file and will delete temp files.

May be what I said is just an imaginary idea….but if I can find out that the file I want to use is locked, then I will be able to implement this approach.

Stuart Dootson2-Mar-09 23:39

GDI+ cause the application freeze

2-Mar-09 23:39

PankajB wrote:
By any mean, can we open any file in exclusive lock mode

Yes - use CreateFile with 0 for the dwShareMode parameter.

Anyway - that scheme sounds feasible Smile | :)

Some points...what happens if you can open the log file but a temp file is locked? Does out-of-order insertion into the log matter?

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

Tal Rasha's Guardianship2-Mar-09 21:52

2-Mar-09 21:52

I have got a trouble of GDI+, my code is like this:

CPaintDC dc(this); // device context for painting
CRect rect;

GetClientRect(&rect);

CDC dcMem;
dcMem.CreateCompatibleDC(&dc);

CBitmap bitmap;
bitmap.CreateCompatibleBitmap(&dc, rect.Width(), rect.Height());

dcMem.SelectObject(&bitmap);

Graphics graphics(dcMem.m_hDC);

SolidBrush brushBKGnd(Color(0,0,0));

//freeze at here
graphics.FillRectangle(&brushBKGnd, Rect(rect.left, rect.top, rect.Width(), rect.Height()));

The code will freeze at the last line, I don't know why, please help me.

Stuart Dootson2-Mar-09 22:32

2-Mar-09 22:32

Well - your code is OK - I've just tried it and it works even if you don't startup GDI+ properly. You do have to remember to blit the bitmap to the window DC to see anything, mind.

So - your code's (superficially) OK - maybe there's something about your setup that's not quite right?

What are the co-ordinates of your rectangle? What happens if you paint to dc rather than dcMem?

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

Tal Rasha's Guardianship3-Mar-09 5:46

3-Mar-09 5:46

I have tried to test the parameters which were sent to FillRectangle function, I found that when they are big numbers(i.e, 200,000), the calling to FillRectangle will freeze.
But from my code, the value of CRect is got from API GetClientRect, does this function have some possibility to fail?

Stuart Dootson3-Mar-09 6:22

3-Mar-09 6:22

Can I suggest you set a breakpoint on FillRectangle and see what the client rect value is?

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

Tal Rasha's Guardianship4-Mar-09 15:35

4-Mar-09 15:35

No，I didn't set breakpoint, I just create a CRect object with large paramaters:
CRect rect(0, 0, 200000, 200000);
//Disable this line
//GetClientRect(&rect);

Stuart Dootson4-Mar-09 21:48

4-Mar-09 21:48

No - get rid of those test parameters and try to find what the rectangle co-ordinates are when the call freezes when the rectangle is derived from the client rect.

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

Tal Rasha's Guardianship4-Mar-09 23:27

4-Mar-09 23:27

I see, thanks for your mention

Tal Rasha's Guardianship5-Sep-09 22:30