|
Cool Thanks,
It's hard too find stuff on that, I've been looking for awhile. I'll going to try SQLOLEDB first and see how that works. I just needed a reference to get started.
|
|
|
|
|
[SQL OleDbConnection.ConnectionString Property]
void CreateOleDbConnection()
{
String* myConnString = S"Provider=SQLOLEDB;Data Source=localhost;Initial Catalog=Northwind;Integrated Security=SSPI;";
OleDbConnection* myConnection = new OleDbConnection(myConnString);
myConnection->Open();
MessageBox::Show(String::Format( S"ServerVersion: {0}\nDataSource: {1}", myConnection->ServerVersion, myConnection->DataSource ));
myConnection->Close();
}
|
|
|
|
|
Thanks for the info. I ended up using SQLNCLI10, the native connector that comes with SQL Server.
What a pain in the ***, well at least till I figure it out. So I can initialize and connect, get a rowset back, just trying figure out how to process the rowset data.
|
|
|
|
|
Hi,
i have a console project. then an console exe.
i want in another project(dlg project), to execute this console exe. i execute it with calling ShellExecute() function.
now, i want to send some messages to this exe.(to send message from dlg to console) how do i do it? i don't have any hWnd of console exe in dlg project!
please help me.
Zo.Naderi-Iran
|
|
|
|
|
Console projects do not have the capability to interact in this way, as they do not have message queues.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
You are trying to do the impossible here, as the other poster stated. But you can pass data between proceses outside of the windows messaging system. Check out interproces communication in the MSDN. Windows hooks are one method I have used a lot.
==============================
Nothing to say.
|
|
|
|
|
A console application does not have a message pump and so cannot accept a windows message. However, you can still communicate with a console application with the help of several IPC mechanisms available (for example - sockets[^], pipes[^], etc.,)
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
As already (correctly) stated you can't use Windows messages to communicate with the console child process. Have a look at an alternative (to the proposed ones) way: "How to spawn console processes with redirected standard handles"[^].
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Windows offers a number of ways for two processes to communicate. See Here[^] Once you decide on a method, you can search for a reference implementation of that method on Code Project to on the net.
|
|
|
|
|
Hi,
For some reason I have been seeing this question alot... and the adequate responses. Although it is correct that console applications initially do not have a message queue... the first time a win32k.sys/GDI syscall greater or equal to 0x1000 is invoked... the windows kernel increases the thread stack-size and invokes KiConvertToGuiThread which will convert the console thread into a GUI thread with a message queue.
How do you 'invoke a system call above 0x1000' ?
WIN32K.SYS System Call Table[^]
As you can see in that table... the first GDI system call NtGdiAbortDoc is at index 0x1000. Because we know that the GetMessage function[^] results in a call to NtUserGetMessage and the DispatchMessage function[^] results in a call to NtUserDispatchMessage. We can infer that by simply creating a message loop... we will have in-fact promoted the thread into a GUI thread.
In other words... by simply attempting to pump the message queue... the thread is given one.
MSG msg;
while(GetMessage(&msg, NULL, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
So what do you have now? Now you have a console process with a thread containing a message queue that has no window HANDLE so cannot recieve window messages. Is this the end of the road?
No, window messages are not the only type of message. You can still use the PostThreadMessage function[^] to post thread messages to the console.
Step 1: Create two console applications... Sender and Reciever.
Step 2: In the reciever begin an infinite message pump (console thread will be promoted to gui thread by the subsystem)
Step 3: In the sender call CreateProcess with the CREATE_NEW_CONSOLE flag that creates the reciever process. (otherwise messages will appear in senders console!)
Step 4: Using the PROCESS_INFORMATION.dwThreadId begin posting messages with PostThreadMessage to reciever from sender.
Best Wishes,
-David Delaune
|
|
|
|
|
Nice.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
How do you create/register the message handler func?
==============================
Nothing to say.
|
|
|
|
|
Hi,
What message handler function are you referring to? The GetMessage function[^] is exported from the user32 library.
Best Wishes,
-David Delaune
|
|
|
|
|
#include <windows.h>
#include <stdlib.h>
#include <iostream>
using namespace std;
#pragma comment(lib, "user32")
int main(int argc, char *argv[], char *envp[])
{
DWORD idThread;
MSG Msg;
if (argc == 2)
{
idThread = atoi(argv[1]);
if (!PostThreadMessage(idThread, WM_COMMAND, (WPARAM)0, (LPARAM)0))
cout << GetLastError() << " PostThreadMessage error\n";
return 0;
}
cout << GetCurrentThreadId() << " thread id\n";
while (GetMessage(&Msg, NULL, 0, WM_USER))
{
if (Msg.message == WM_COMMAND)
cout << "WM_COMMAND\n";
else
cout << "Message: " << Msg.message << endl;
}
return 0;
}
|
|
|
|
|
|
If you have access to the console app source code, and you go to the trouble of adding the message pump, you may as well add code to create a message-only window, no?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Hi Richard,
Richard Andrew x64 wrote: you may as well add code to create a message-only window, no?
It doesn't really matter to me how you decide to implement IPC between console applications. As Rajesh suggested you could use sockets, pipes or as Carlo Pallini suggested you could use STDIN/STDOUT/STDERR or as you suggested a hidden window or the option I have suggested; PostThreadMessage. It is great to have so many options put on the table. 
Best Wishes,
-David Delaune
|
|
|
|
|
Yep, definitely not impossible (people get too used to the framework doing magic)... I think it's just a bit of a hassle more than anything else. Good job pointing this out! 
|
|
|
|
|
It is not possible but you can cheat. Reverse engineer it.
Create a Windows app (win32 or MFC) and redirect messages to a console window.
But once you add a window, your app will no longer be a console app.
So it is still not possible.
See [this].
More reversed console apps [here] and [here].
|
|
|
|
|
Here is another example, to go along with Carlos'.
"One man's wage rise is another man's price increase." - Harold Wilson
"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
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
Hi,
I have gotten arount Most of the security challenges around the New Windows Model.
One issue remains a challenge. I created a derrived MFC Control: 'CMultiColumListBox', derived from MFC-'CListBox'. It in turn, is used as a Baseclass for various data tabulations. it all works to perfection under Win 95/98. Win NT, and Windows XP. With Vista and Windows 7, the Header Button listtakes up about 80% of the width of the CListbox Window, the Text Colums take up even Less.
One part of the creation process sets up the display Geometry parameters. I must have missed a Translation Somewhere.
The Salient part of the control that does this is as follows:-
BOOL CMultiColumListBox::RegisterControl(CDialog * pDialog)
{
if(!m_bDrawButtons)return TRUE;
ASSERT(pDialog->IsKindOf( RUNTIME_CLASS(CWnd) ) );
ASSERT(::IsWindow(pDialog->m_hWnd));
CDC* pDC=pDialog->GetDC();
ASSERT(pDC);
m_pParentDialog=pDialog;
CRect CtrlRect,DlgWndRect,DlgClientRect,BnRect;
GetWindowRect(&CtrlRect); pDialog->GetWindowRect(&DlgWndRect);
pDialog->GetClientRect(&DlgClientRect);
int BorderWidth=DlgWndRect.Width() - DlgClientRect.Width();
int TitleBarHeight=DlgWndRect.Height() -
DlgClientRect.Height()-BorderWidth;
BorderWidth/=2;
int Base_x,Base_y,BaseWidth;
Base_x=CtrlRect.left-1;
Base_y=CtrlRect.top;
BaseWidth=CtrlRect.Width();
for(int i=0;i<m_nNrOfColumns;i++){
CWnd* pWnd=pDialog->GetDlgItem(m_nColumList[i].n_ID);
ASSERT(pWnd);
pWnd->ShowWindow(SW_NORMAL);
int Width=m_nColumList[i].width;
if(i==m_nNrOfColumns-1)Width=BaseWidth;
if(Width>BaseWidth)Width=BaseWidth;
BnRect.left=Base_x-DlgWndRect.left-BorderWidth;
BnRect.right=Base_x+Width-DlgWndRect.left-BorderWidth;
BnRect.top=Base_y-m_nItemHeight*2-TitleBarHeight-DlgWndRect.top-1;
BnRect.bottom=Base_y-TitleBarHeight-DlgWndRect.top-1;
pWnd->MoveWindow(&BnRect); Base_x+=Width;
BaseWidth-=Width;
char* p=m_nColumList[i].lpcstrColumHeader;
if(p)pWnd->SetWindowText(p);
}
return TRUE;
}
This function would Typicaly be called from OnInitDialog()from the Dlg that contains it. It sets the Parameters for subsequent Drawing and Painting.
Any Idea about DlgToScreen() ScreenToDlg(),etc tha should have been used here
Bram van Kampen
|
|
|
|
|
i have a character arry in C
hello hi soidjosdc
kcopsdkcpok cjsdp
dskcoksdpc ocsdkcpd
i want to read it line by line and store it in another array....please help
|
|
|
|
|
please give any suggestions
|
|
|
|
|
Okay, I'll byte..
In essence, you have a string that you have to cut up into smaller pieces.
The cut-points are clearly defined - the string is to be cut at the end of each line of text.
So, we need
1) knowledge of the number of lines
2) memory to hold each of the lines
3) to copy each of the lines to the memory allocated in step 2.
Sooo, you'll need to know what your line-ending character(or sequence) is. You'll need to count the number of instances of the of line terminators, and for ease and simplicity, add 1 to this number - this is the number of lines you have - mLineCount.
You can then create an array of mLineCount elements of char*
You can then copy each line, storing the address of the new text into the appropriate array element.
Two functions you'll likely make use of are strdup and strtok. I advise you read the documentation for these two functions carefully, there are a few gotchas or things to watch for with strtok - Particularly, the fact that it modifies the input string. This precludes the use of the function on const char* strings.
For example, while the intention below is to split "some text" into two separate strings, it will fail since strtok can't modify myString.
char *myString = "some text", *delims = ",. ";
char *curToken;
curToken = strtok(myString, delims);
|
|
|
|
|
I and others already answered a similar query below. If you still don't understand string parsing then you need to spend a lot of time reading the MSDN documentation and sample code on the functions I recommended to you.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
