i think this is the problem: newDataRow["Timestamp"] = DateTime.Now.ToString(); if your database field is a text field use newDataRow["Timestamp"] = Convert.ToString(DateTime.Now); and if it's a datetime (much better) use it this way newDataRow["Timestamp"] = DateTime.Now;

Apart from your normal registration, the Addin also has to register itself with the respective office application (in your case Excel). Check the below article on msdn, HOW TO: Build an Office COM Add-in by Using Visual C# .NET[^] Cheers, Kannan

Try moving the creation of the dialog into a handler in the list view class. Then all you can just pass a pointer to the view to the dialog in the dialog's ctor. CYourDialog wndYourDialog ( this /* the view */ ); Where your dialog's ctor looks something like this; CYourDialog::CYourDialog ( CYourView * pView ) : m_pTheView ( pView ) {} Then just add the items to the view from the dialog throught the pointer to the view. Ben Burnett --------- On the topic of code with no error handling -- It's not poor coding, it's "optimistic" ;)

The best way to do this is to get the folder from the application .EXE path. To do that, you need to use the Win32 API GetModuleFileName(). That API will return the complete pathname of the calling process' EXE. Unfortunately, it can return an 8.3 style filename and can mangle your directory names. I've included a Win95 safe short->long pathname conversion function ( Win95 doesn't support this ). Finally, once you have a nice looking path, you chop off the .EXE name path off with another funciton I've included GetPathOnlyFromPathname. CString MyPath = GetPathOnlyFromPathname(GetLongPathname(GetAppPathname())); where you have the following 3 utility functions: CString GetAppPathname(void); CString GetLongPathname(const CString & ShortPathname); CString GetPathOnlyFromPathname(const CString & PathName); // returns the full pathname of the application CString CVChatApp::GetAppPathname(void) { char szAppPath[2048]; GetModuleFileName(NULL, szAppPath, sizeof(szAppPath)); return (GetLongPathname(szAppPath)); } The GetModuleFileName call will return an 8.3 style pathname to the EXE. You may want to convert that into a long filename so the directory name doesn't get mangled: // convert a short DOS type 8.3 pathname to a Long Filename is the // version of Windows support the export of the "GetLongPathName" API ( Win95 doesn't ) CString GetLongPathname(const CString & ShortPathname) { CString FullPath; // Win95 doesn't have the GetLongPathName function, // so we need to check the dll to see if it exists to avoid // a fatal run-time error. // Also, note that the name of the function as specified in the DLL // is different than the called name, due to UNICODE macro preprocessors // AND, I think GetLongPathName is a pascal-style called function, so // have to add __stdcall (__cdecl is the default, which is buggy) HMODULE hm; hm = GetModuleHandle("kernel32.dll"); typedef unsigned long (__stdcall *PFI)(LPCTSTR lpszShortPath, LPTSTR lpszLongPath, DWORD cchBuffer); PFI pGetLongPathName; FARPROC pTemp; pTemp = GetProcAddress(hm, "GetLongPathNameA"); char strLongName[MAX_PATH]; strcpy(strLongName, ""); if (pTemp != NULL) { DWORD dw; pGetLongPathName = (PFI)pTemp; dw = (*pGetLongPathName)(ShortPathname, strLongName, MAX_PATH); } else { strcpy(strLongName, ShortPathname); } FullPath = strLongName; return FullPath; } and you'll need one other function: CString GetPathOnlyFromPathname(const CString & PathName

Try to set CSize paneSize(200,200); then try to handle the OnSize message as follows: void CMainFrame::OnSize(UINT nType, int cx, int cy) { CFrameWnd::OnSize(nType, cx, cy); CRect cr; if ( m_initSplitters && nType != SIZE_MINIMIZED ) { m_mainSplitter.GetClientRect( &cr ); m_mainSplitter.SetColumnInfo( 0, cr.Width() / 2, 0 ); m_mainSplitter.SetColumnInfo( 1, cr.Width() / 2, 0 ); m_mainSplitter.RecalcLayout(); } } m_initSplitters is a BOOL set to TRUE after the splitters have been created in the OnCreateClient-function. Use this function to create your splitters instead of the OnCreate function regards!

I'm having the same problem with a different ActiveX control I'm using in a modeless dialog from within a DLL. For some reason it seems as though the ActiveX control is not being created properly during the call to Create(). Mine always has a NULL hWnd after the call to create so whenever a method on the control object gets called it bombs out with that same assertion error you're getting because the control has actually not been created properly. I wish I had a solution for you, this one is driving me crazy!