|
Dunno, a book on ADO ? O'Reilley have a good one, from memory.
Christian
No offense, but I don't really want to encourage the creation of another VB developer. - Larry Antram 22 Oct 2002
Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002
Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002
|
|
|
|
|
Simple solution - use OpenSchema method of ADO Connection object:
pConn->OpenSchema(adSchemaTables,vParams)
where vParams is a Safearray containing the following null, schema_name, null, null. This then returns a recordset which contains all of the tables in the schema. To enumerate the fields of a table, use similar:
m_pConn->OpenSchema(adSchemaColumns, vParams)
where vParams contains null, schema_name, table_name, null. Again returns recordset that can be used to get all sorts of information.
If you need a fuller example, fell free to e-mail me. vParams cna be used to control the operation in a much more detailed way than here, but this provides basic naming information.Also, has the advantage that will work with any DB type (SQLServer, Oracle, Access etc).
Hope it helps
|
|
|
|
|
Hi, I have an CEdit control which can be resized. The user can switch from a single line edit control to a multi line control if he decides so.
How do I detect the number of lines (a CEdit can hold not actually has)? I need to catch the switch from a single - to multi line layout and change some atributes.
Thanks
|
|
|
|
|
|
Do you mean visible lines in the edit control? There is no limit to the number of lines a control can have upto the 64K byte limit of \r\n pairs 63336/2 = 32768 possible lines held.
If its just the number of lines the control could display without a scrollbar, then you can compute this by gettting the client area size of the control, the DC and the font, and then count the number of lines like this:
int ComputeLines(int ID)
{
CWnd *pWnd = GetDlgItem(ID) ;
if (!pWnd)
return 0;
CEdit *pEdit = static_cast<CEdit*>(pWnd);
if (!pEdit)
return 0 ;
CDC *pDC = pEdit->GetDC() ;
CFont *pFont = pEdit->GetFont();
CFont *pOldFont = pDC->SelectObject(pFont);
CRect rect ;
pEdit->GetCLientRect(&rect);
CSize size = pDC->GetTextExtent("A", 1);
pDC->SelectObject(pOldFont);
ReleaseDC(pDC);
return rect.Height() / size.cy;
}
OK, the above it untested and types directly so, it may, may not work correctly
Roger Allen
Sonork 100.10016
I have a terminal disease. Its called life!
|
|
|
|
|
Roger Allen wrote:
If its just the number of lines the control could display without a scrollbar, then you can compute this by gettting the client area size of the control, the DC and the font, and then count the number of lines like this:
thousand thanks, Roger! 
|
|
|
|
|
PS: instead of GetDC/ReleaseDC I might better use a CClientDC(this), which is an MFC encapsulation of this AFAIK.
|
|
|
|
|
Just came across this. Very good sample collection on connection string format, just want to share it with u all:
http://www.able-consulting.com/MDAC/ADO/Connection/OLEDB_Providers.htm#OLEDBProviderForSQLServer
And to moderator:
is it possible that u put a similar tutorial on your site? It's very handy and will be very helpful later on.
Thanks.
norm
norm
|
|
|
|
|
|
I have a background in my CListCtrl. I don't want it to scroll though. How does one stop that from happening? Thanks for any help.
|
|
|
|
|
Repaint the background everytime you do any scroll event, perhaps?
But you'll need to double buffer your painting to prevent flicker I think!
Perhaps not much for help this but anyway...
Rickard Andersson@Suza Computing
C# and C++ programmer from SWEDEN!
UIN: 50302279
E-Mail: nikado@pc.nu
Speciality: I love C#, ASP.NET and C++!
|
|
|
|
|
I was wondering if anyone here has had any experience with using Waitable timers.
I am in the process of writing a scheduler, similar to SQL Server's Job scheduling utility. The reason i need it is because SQL server doesn't meet all of my criterias.
Now, I have been reviewing various ways of scheduling jobs and I posted earlier on this topic, except for it got buried under various other posts.
I was wondering whether Waitable Timers or TimerQueues are good candidates for a scheduling device? I guess what I would be doing is create all these timers for every job scheduled and then waitonmultiple objects. And I guess my WaitOnMulitple object parameter must be set to true, to allow things to go through as soon as they are signalled.
So, are there any issues and problems that these two suffer from?
thanks
|
|
|
|
|
I'm ranging through a CEdit object's lines, but every time I do the following, LineLength() returns the length of the first edit line. 
Any help? I understand this function, LineLength(i), to return the length of the edit control line, whose index is zero-based, i. That much is correct, right?
CString sLine;
for(int i=0; i<m_Edit->GetLineCount();i++)
{
m_Edit->GetLine(i, sLine.GetBuffer(m_Edit->LineLength(i)), m_Edit->LineLength(i));
...
...
}
BW
"I'm coming with you! I got you fired, it's the least I can do. Well, the least I could do is absolutely nothing, but I'll go you one better and come along!"
- Homer J. Simpson
|
|
|
|
|
Have you tried the following instead?
CString sLine;
for(int i=0; i<m_edit->GetLineCount();i++)
{
m_Edit->GetLine(i, sLine);
...
...
}
(I would've tried this on my machine -- but I'm building a huge project at the moment..)
"No one goes to hell because of their sin, but because of rejecting God's method of salvation: His Son's life for yours..."
"It does not take a majority to prevail ... but rather an irate, tireless minority, keen on setting brushfires of freedom in the minds of men." --Samuel Adams
|
|
|
|
|
The MSDN says LineLength returns the length of the line which contains the character at index "nLine" (I know, great way to name the parameters MS!). So, to get the length of a specified (actual) line index, we'll use LineIndex in conjunction with LineLength:
m_Edit->GetLine(i, sLine.GetBuffer(m_Edit->LineLength(i)), m_Edit->LineLength(m_Edit->LineIndex( i )));
Chris Richardson
Programmers find all sorts of ingenious ways to screw ourselves over. - Tim Smith
|
|
|
|
|
BTW, this worked for me.
Thanks!
BW
"I'm coming with you! I got you fired, it's the least I can do. Well, the least I could do is absolutely nothing, but I'll go you one better and come along!"
- Homer J. Simpson
|
|
|
|
|
Hello everyone,
I have a question about multithreading and syncing data. I have two threads A and B; A feeds data to a cache in B then waits until B is finished with its cache. Example in Pseudo code:
The Mutexes were taken out for code clarity.
A thread:
{
for (I=0; I < 5; ++I)
B->loadData(i);
B->Wait(); // Now wait for thread B to finish processing data.
...
}
B Thread
{
Handle dwWait;
Handle dwRun;
Vector<int> vI;
ThreadFunc()
{
while (1)
{
WORD wdCheck = WaitForSingleObject(dwRun, INFINITE);
switch (wdCheck)
{
case: 0
{
for (int I = 0; I < vI.size(); ++I)
...
SetEvent(dwWait); // Now vector is empty send event.
}
case: 1
{
}
}
}
void Wait()
{
WaitForSingleObject(dwWait, INFINITE);
}
void loadData(int I)
{
vI.push_back(I);
SetEvent(dwRun);
}
}
My question is, why doesn’t thread A always wait for Thread B to finish before continuing on.
Thanks in advance.
Ken
|
|
|
|
|
The key is in the piece of pseucode:
for (I=0; I < 5; ++I)
B->loadData(i); This feeds the cache with 5 ints, signalling dwRun after inserting each int. So, imagine the following (possible) pattern of execution:- A feeds the 1st
int.
- A sets
dwRun.
- The system yields controls to B.
- B processes the cache (containing only one
int) and sets dwWait.
- The system yields controls to A.
- A loads the remaining four
ints, setting dwRun after each insertion.
- A
Waits and exits immediately, as dwWait is already set. There's still some data in B's cache.
See the problem now?
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Thanks for your help and time, Joaquín 
I see, so the event is already set by the time the wait function is called by A. Thus that is why Thread A does not always wait for Thread B. So how would one go about fixing this dilemma? Perhaps by putting another mutex around the wait function call? Or maybe use a while loop in the Wait function that checks if the vector is empty? Are there any examples of something like this that I could refer to?
Example:
void Wait() // While loop checking size of vector.
{
while (vI.size() != 0)
WaitForSingleObject(dwWait, INFINITE);
} // But this does not seem like a very clean solution.
Thanks again for your help.
Ken
|
|
|
|
|
The easiest solution is probably to split LoadData into two functions, say LoadData and Run, the first feeding the cache and the second setting dwRun, and call Run only when finished pushing the data.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Thanks again.
Another possible solution that I came up with, which is to reset dwWait in the Wait function. This seems to work??? But I'm wondering if there is an even cleaner way to solve this?
Example:
void Wait()
{
if (vI.size() != 0)
{
ResetEvent(dwWait); // This will make sure to wait for event.
WaitForSingleObject(dwWait, INFINITE);
}
}
Thanks for all of the help.
Ken
|
|
|
|
|
Watch out, this solution you propose is broken! The possibility of deadlock is minimal, but this is even worse, as chances are you don't notice anything till it's too late and the app has been released. Counterexample:- A feeds the data.
- A checks
vI.size()!=0. This evaluates to true (B has not been given access by the system yet).
- Thread switch: B begins executing, process the whole data and sets
dwWait.
- Thread switch: A resets
dwWait and wait for completion --for ever.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Hi again,
Ok, here is my latest attempt to resolve this.
Handle mMutex;
mMutex = CreatMutex(...);
ThreadFunc()
{
while (1)
{
WORD wdCheck = WaitForSingleObject(dwRun, INFINITE);
switch (wdCheck)
{
case: 0
{
WaitForSingleObject(mMutex, INFINITE); // New code here.
for (int I = 0; I < vI.size(); ++I)
...
ReleaseMutex(mMutex); // New code here.
SetEvent(dwWait); // Now vector is empty send event.
}
case: 1
{
}
}
}
void Wait()
{
WaitForSingleObject(mMutex, INFINITE); //New code here.
if (vI.size() != 0)
{
ResetEvent(dwWait); // This will make sure to wait for event.
ReleaseMutex(mMutex); // New code here.
WaitForSingleObject(dwWait, INFINITE);
}
ReleaseMutex(mMutex); // New code here.
}
Wooweee, I think I got it right this time.
Again thanks for all of your help.
Ken
|
|
|
|
|
Is there a way to prevent a modal dialog from closing when a user initiates the WM_CLOSE?
I'm handling WM_CLOSE message using my own OnClose() where I display a message box with YESNOCANCEL. If the user selects CANCEL I want to return them to the current dialog, unharmed. I tried just returning before executing CDialog::OnClose(), but it still closes and ends the application.
I've read many suggestions within the forum and nothing seems to do what I want, all result in the dialog closing and app ending.
-kg
Ken Goguen
|
|
|
|
|
This is done Handling the WM_CLOSE..
void CTestDlg::OnClose()
{
if(MessageBox("Close?","Really?",MB_YESNOCANCEL)== IDYES)
{
CDialog::OnClose();
}
else
{
}
}
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
