|
yeah, I found a piece of code here on CP to do what I needed. I think it's simpler to just #define VERSION_NUMBER _T("1.8") as I've been doing. That seems like an awful lot of work to get the version number info from your own app. I think it should be a member of CWinApp, personally.
theApp.m_strVersionNumber or something like that. Thanks, though.
[insert witty comment here]
bdiamond 
|
|
|
|
|
Anybody knows how to avoid the user to edit the date in a datetimepicker control ?
I only want the user to be able to open the calendar when he/she clicks on the arrow and pick a date from that month calendar, but not be able to change the date in the edit fields.
-------------------------------
[Wednesday, September 22, 2004] <- not allow to change in that portion
-------------------------------
| sun mon tue wed thu fri sat |
| 1 2 3 4 5 6 7 | <- ok to use the popop calendar
| 8 9 10 11 12 13 14 |
| 15 16 17 18 19 20 21 |
| 22 23 24 25 26 27 28 |
| 29 30 |
-------------------------------
thanks.
Lou
* how do you like my datetimepicker control ? 
|
|
|
|
|
in MSDN this is written :
"To jump to a page other than the next one, return the identifier of the dialog to be displayed."
should it be something like that :
LRESULT CMyPropertyPage1::OnWizardNext()
{
BOOL b = m_Choose.GetCheck();
if ( m_Choose.GetCheck() == TRUE )
return 1;
else
return 3;
}
to go to either page 1 or page 3 ?
because it doesn't seem to work ? Am I missing something ?
Thanks.
Max.
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
"the identifier of the dialog" means the dialog resource ID, eg IDD_FINISHING_PAGE.
--Mike--
Personal stuff:: Ericahist | Homepage
Shareware stuff:: 1ClickPicGrabber | RightClick-Encrypt
CP stuff:: CP SearchBar v2.0.2 | C++ Forum FAQ
----
Four fonts walk into a bar. The bartender says "Hey - get out! We don't want your type in here."
"That probably would've sounded more commanding if I wasn't wearing my yummy sushi pajamas."
-- Buffy
|
|
|
|
|
|
Hi there,
I have recently finished a collection of classes which provide support for database processing. The only problem though is the classes use the (old-deprecated) ODBC API.
Some time ago I was told ADO data source connectivity is a much better approach because of its ease of use, speed and so forth. This made me think about updating (or actually rewritting) the entire collection so that it can support the latest in what regards to datasource connectivity.
But I have been doing some reading and would like to ask you some questions:
- doesn't ADO use OLEDB? And if so, should I not be thinking about supporting OLEDB rather than ADO as it would create an additional layer between the ODBC driver and the App?
- in what concerns compatibility and speed, what is, in your own opinion, the platform I should be aiming for?
Thank you very much,
David
|
|
|
|
|
I think the time needed to load the data from hard disk takes much longer than the time to process requests and transfer them via ODBC.
I myself use ODBC, too, and I don't see any reason why I shouldn't do so.
Don't try it, just do it! 
|
|
|
|
|
Yes, ADO uses OLEDB. Using OLEDB will give you the most functionality and performance. Consider using ATL wrapper classes, they'll make it easier. For example:
<br />
HRESULT hr = spDataInitialize.CoCreateInstance(CLSID_MSDAINITIALIZE);<br />
if(FAILED(hr)) return 1;<br />
<br />
hr = spDataInitialize->GetDataSource(NULL, CLSCTX_INPROC_SERVER, pwszConnectionString,<br />
IID_IDBInitialize, reinterpret_cast<IUnknown**>(&spDBInitialize));<br />
if(FAILED(hr)) return 1;<br />
<br />
hr = spDBInitialize->Initialize();<br />
if(FAILED(hr)) return 1;<br />
<br />
ATL::CComQIPtr<IDBCreateSession> spDBCreateSession = spDBInitialize;<br />
if(!spDBCreateSession) return 1;<br />
<br />
hr = spDBCreateSession->CreateSession(NULL, IID_IDBCreateCommand, reinterpret_cast<IUnknown**>(&spDBCreateCommand));<br />
if(FAILED(hr)) return 1;<br />
<br />
hr = spDBCreateCommand->CreateCommand(NULL, IID_ICommand, reinterpret_cast<IUnknown**>(&spCommand));<br />
if(FAILED(hr)) return 1;<br />
<br />
ATL::CComQIPtr<ICommandStream> spCommandStream = spCommand;<br />
if(!spCommandStream) return 1;
|
|
|
|
|
Let's try this again, this time with the angle brackets..
HRESULT hr = spDataInitialize.CoCreateInstance(CLSID_MSDAINITIALIZE);<br />
if(FAILED(hr)) return 1;<br />
<br />
hr = spDataInitialize->GetDataSource(NULL, CLSCTX_INPROC_SERVER, pwszConnectionString,<br />
IID_IDBInitialize, reinterpret_cast<IUnknown**>(&spDBInitialize));<br />
if(FAILED(hr)) return 1;<br />
<br />
hr = spDBInitialize->Initialize();<br />
if(FAILED(hr)) return 1;<br />
<br />
ATL::CComQIPtr<IDBCreateSession> spDBCreateSession = spDBInitialize;<br />
if(!spDBCreateSession) return 1;<br />
<br />
hr = spDBCreateSession->CreateSession(NULL, IID_IDBCreateCommand, reinterpret_cast<IUnknown**>(&spDBCreateCommand));<br />
if(FAILED(hr)) return 1;<br />
<br />
hr = spDBCreateCommand->CreateCommand(NULL, IID_ICommand, reinterpret_cast<IUnknown**>(&spCommand));<br />
if(FAILED(hr)) return 1;<br />
<br />
ATL::CComQIPtr<ICommandStream> spCommandStream = spCommand;<br />
if(!spCommandStream) return 1;
|
|
|
|
|
ADo wraps OLEDB.
ADO has had some bugs and portability issues (to WinCE).
I think most have been sorted out but it has left a sour taste in the mouths of some of us - i don't use it.
ODBC is a cleaner API (in my opinion) than OLEDB - i am not a fan of COM.
That said, ODBC is not supported by WinCE but OLEDB is.
So i have database classes that wrap both ODBC and OLEDB but provide a common method interface.
I generally use ODBC on the desktop and OLEDB on WinCE.
...cmk
Save the whales - collect the whole set
|
|
|
|
|
Hi and thanks for replying.
It is interesting to know you are (also) an adept of the ODBC_API... but looking at both the ODBC_API and OLEDB what would you say about performance issues such as:
- memory usage;
- processing speed (in the general sense);
And what about the future? I mean, do you think ODBC will still be supported in the future or will it be made deprecated by Microsoft?
#David
|
|
|
|
|
dNimrod#X wrote:
looking at both the ODBC_API and OLEDB what would you say about performance issues such as:
- memory usage;
- processing speed (in the general sense);
I've never compared them head-to-head.
I almost always use ODBC on desktop and OLEDB on PDA - you can't compare the relative speeds due to the difference in the platforms.
At this point i wouldn't expect to find much of a performance difference between the two. Any difference would likely be dwarfed by the time required for the RDBMS to execute the query.
dNimrod#X wrote:
do you think ODBC will still be supported in the future or will it be made deprecated by Microsoft?
I don't know.
I don't think it will be depreciated any time soon (knock on wood).
ODBC has an open source port for UNIX (MAC?) so it is now truely a cross-platform API.
http://www.odbc.org/[^]
http://www.iodbc.org/[^]
...cmk
Save the whales - collect the whole set
|
|
|
|
|
Is there an easily way to create an escaped Window's path, or is there a better way to do this?
I have code that gets a path from a CFileDialog then I want to open the file with fopen because I want the code to be portable.
example:
CFileDialog fileDlg;
CString fileName = fileDlg.GetPathName();
FILE *file = fopen(fileName, "r");
I've done google searches but found nothing helpful, unless I'm using C# in which case they have @"" strings that handle this nicely.
Thanks
Hua-Ying
|
|
|
|
|
What you have is fine, except that fileDlg.DoModal() needs to be called.
BTW, why are you using a FILE object rather than a CFile object?
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
Thanks for pointing that out. I am calling fileDlg.DoModal() in the real code, I didn't put it in the sample code for simplicity. I'm using FILE instead of CFile for portability. That code needs to run under other platforms such as Linux.
The problem is fileDlg returns a string in this format: "c:\testfile.txt" but fopen wants this: "c:\\testfile.txt".
|
|
|
|
|
hyling wrote:
That code needs to run under other platforms such as Linux
So does the Linux platform support CFileDialog?
hyling wrote:
The problem is fileDlg returns a string in this format: "c:\testfile.txt" but fopen wants this: "c:\\testfile.txt".
Only if you are using a string literal are double backslashes required. When the compiler encounters a backslash, it treats the next character as special (e.g., \n, \t, \a). Since the backslash character is special in and of itself, it must be preceded by a second backslash.
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
CFileDialog will be replace with the Linux equivalent for the port.
fopen seems to only accept an escaped string even if it is not a string literal, ie. when CFileDialog returns an unescaped string fopen can not open the file.
I understand how an escaped string works. I should have been more explicit. I'm asking, is there an easier way to get an escaped version of the string without having to write my own code to escape the '/' in the path. I don't have a problem with writing that code, but I don't want to reinvent the wheel.
Thanks
Hua-Ying
|
|
|
|
|
hyling wrote:
I'm asking, is there an easier way to get an escaped version of the string without having to write my own code to escape the '/' in the path. I don't have a problem with writing that code, but I don't want to reinvent the wheel.
I do not know of a function, other than writing your own to replace each \ with \\, because up until today, I did not know it was necessary.
Have you tried this same experiment on a Windows box?
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
You're right, escaping the string isn't necessary unless it is a string literal. I was confused by the VS.net debugger, which puts a summary of the elements of the FILE structure beside the pointer, the first element of the FILE * happened to be "0(Bad Ptr)", but the FILE * itself was good. Err.. . maybe I just need more caffeine. 
Now I know why nobody else on the net or discussion boards had problem...
Thanks for your time. 
Hua-Ying
|
|
|
|
|
Hi,
I created an MDI doc/view application using the wizard. I wanted to have one document that stores some data. One view that has controls and displays the data in drop down lists etc (I achieved that by subclassing CFormView, it works). But now I want to add a view that displays some graphics (I can do that by override the CView and override the OnDraw()) but how do I make it use the same document as the other view? Making another document class doesn't make much sense in my design and also I'd need to communicate between 2 documents to share some data which I don't want to do.
Also I see the implementation of GetDocument() which simply returns m_pDocument. However I can't find this variable in any header file. And the MFC reference I have doesn't list it in the CView class. And any of the code generated by the AppWizard doesn't create any views explicitly. How can it the constructor is private. Yet it all works It's all magic.
Any ideas/help? Thanks.
|
|
|
|
|
You are doing something that does not mesh well with the doc/view architecture, and whenever you do that, you have to start digging into the behind the scenes stuff that Microsoft doesn't readily expose to you.
You might want to think about using an SDI setup, create it with a splitter window, then use your own management of added CDocument derived objects. It is sometimes easier to construct than to deconstruct the AppWizard code
|
|
|
|
|
I don't have much experience with MFC so it's hard for me to decide the best way to go about designing the GUI. I would rewrite what I have now if there was a better way (such as splitwindows you suggest).
I don't even care for the CDocument since I don't use files. I can manage the data myself. What I do need though is some place to put some controls and some place to be able to draw pixels (jpeg data, or even graphs that I generate). I don't like the Dialog based application so I need to override the CFormView in order to insert controls into my MainFrame unless there's another way. So if I split the window would I be able to use 2 different View objects? The example I have from Code Project uses the same view on both sides.
Also if I add a Picture control can I somehow draw within those bounds (easily)? Can I draw on the CFormView and still display controls that work (easily)? That would eliminate the need for 2 Views.
That's a lot of questions...Thanks.
|
|
|
|
|
You do need an SDI then. You don't need CodeProject on this one, just look in the MS Help files for CSplitterWnd and there is a pretty good description and examples right there
You use the original view and then add another view and overide your own GetDocument() for it. Then create some system to logically update them when needed to correspond with your data. I just save pointers to each view in the OnCreateClient where you set up your CSpitterWnd in CMainFrame. But you can also use a system of sending update messages (The proper but annoying way)
You don't necessarily have to use the Doc/View system, but it saves you some trouble. It takes care of recent file lists, "are you sure you want to save that..." etc. etc. If you tinker with it expect to have to do some extra work to take care of these details.
If you override OnOpenDocument OnSaveDocument you interrupt the doc/view system, and can handle it any way you want.
Personally I have never used straight doc/view as it restrictive and simplistic.
|
|
|
|
|
I'll try that.
Just to confirm the following code creates the views:
m_wndSplitter.CreateView(0,0,RUNTIME_CLASS(COneView), CSize(0,0),
pContext);
m_wndSplitter.CreateView(1,0,RUNTIME_CLASS(CAnotherView), CSize(0,0),
pContext);
You save the pointer to the created view by calling GetPane(row, col) correct?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
