|
Hi everybody,
i made a buffer-CEdit where i rely a char* with a CEdit.
how can i store the char* from the View into the CEdit?
i create the View-Variables like this:
char *var = (char*)malloc(sizeof(char)*50);
My own CEdit derived texbox:
MyCEdit tbNumber (Creation via DDX)
then i "link" the string with the Textbox
tbNumber.Link(&var);
where MyCEdit has a
char** InternBuffer;
and the "linkage" is made this way:
void MyCEdit::Link(char** var_t)
{
InternBuffer = var_t;
}
But it doesn't work, i tried some other possibilities, but i always get another pointer value
There is seriously a simple * mismatch
Thanks for help
|
|
|
|
|
Why are you doing this? One of the major selling points of using MFC is that you don't need to mess around with char -type variables, especially where the memory manager is concerned.
if you need the txt within an edit control, simply use:
CString str;
tbNumber.GetWindowText(str);
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Thanks for your answer,
i like to develop this kind of trading to minimize the lines of code.
at the window i have class-member strings which are always up-to-date with the
content of the textbox.
Because if i have 10 textboxes on a view and they'll filled with data from out a database
then the user can modify the content and at the destruction of the view all the contents of the
textboxes are re-stored into the database.
In this case i have to GetWindowText 10times and SetWindowText 10times.
If the view performs other special functionalities i Get/Set more than 2-3times.
Since now i always do it in your way, but i try to keep the DOS-Programming way, for that
my work-partners, which works only in DOS programming could understand more faster my application.
Because i copy the existing DOS-Applic 1:1 into MFC
And i don't have the time to change all the logic from DOS-to-Windows Programmatic-System
I know that all this is strange, but it's my work
|
|
|
|
|
I fail to see what any of this has to do with using char* rather than CString variables. If your coworkers are unable to work with CString , then they are also unable to work with CEdit .
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
baerten wrote: tbNumber.Link(&var);
I really hope that var isn't a local variable, elseway InternBuffer (=&var ) become soon unuseful.
Russell
|
|
|
|
|
Nope, var is in this case a class-member and if not, anyway allocated dynamically via malloc
thanks anyway for help
|
|
|
|
|
Then it seems that it must work.
Can the problem be on the way you get the value?
char Val=(*InternBuffer)[MyPreferredCharInTheString];
Russell
|
|
|
|
|
i perform into Link(char **var_t) :
void MyCEdit::Link(char** var_t)
{
InternBuffer = var_t;
SetWindowText(*var_t);
}
then i get an error into the message loop of the window-thread
if i set the InternBuffer = var_t; line as comment :
void MyCEdit::Link(char** var_t)
{
//InternBuffer = var_t;
SetWindowText(*var_t);
}
it works and the textbox gets the correct string. And no error occurs.
If i re-insert the InternBuffer = var_t; line it crashes during a message loop, for example
with a SetText-Message or Paint-Message of a pWnd->WindowProc(....
Thats the strange action, my "pointer problem" is correct
|
|
|
|
|
I haven't enough information.
But are you sure that you can't use an internal buffer like this:
char* InternBuffer ;
It seems the simpler way: i.e. a simple string, I think that your problem cames somwhere in your code from your char** solution.
Russell
|
|
|
|
|
Ok, InternBuffer is set to char*
initialised via "InternBuffer = var_t;" and NEVER used...
InternBuffer = var_t; --> makes problem
//InternBuffer = var_t; --> no problem
Sometimes i have some strange error that i think there is a huge bug in my whole project
|
|
|
|
|
char** => char* should do the work.
Wouldnt it be easier to give the MyCEdit a public char[] member?
Greetings from Germany
|
|
|
|
|
Nice idea,
i will try it, so i need to write at the code
mytextbox.Value
Thanks
|
|
|
|
|
Hi,
Am displaying some label controls, and a list control in a dialog bar. The label controls are there for the user to select colors. When the user selects some five rows in the list control, and selects any of the label controls, i need to color those selected five rows with the color of the label control selected. how to achieve this?
With Regards,
Sangeetha.
|
|
|
|
|
Did you use of NM_CUSTOMDRAW on your project? I think Michael Dunn has a good article about customize list control ?
|
|
|
|
|
Hi
I need to call OnBconnect() event somewhere in my application initialisation so that i do not need to press the button "Connect".
void CRantView::OnBconnect() <br />
{<br />
UpdateData(TRUE);<br />
m_sConnectSocket1.Create();<br />
m_sConnectSocket1.Connect(m_strIP1,m_iPort1);<br />
GetDlgItem(IDC_BCONNECT1)->EnableWindow(TRUE);<br />
}
The idea is that i automatically connect to the socket.
But i get an error something like UpdateData() called before DoModal...similarly for GetDlgItem()
which would be the right place to call this connect-function?? I had tried in View's constructor where i got this error...
|
|
|
|
|
Lose the call to UpdateData() . It'll only add to your frustration.
Is CRantView derived from some CView class? If so, you can't call OnBconnect() method until the view has been fully rendered (e.g., in OnUpdate() , which is called by OnInitialUpdate() ).
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
It is derived from CRecordView and i m facing this problem becauce of UpdateData() and GetDlgItem().....when i comment these two lines it works fine.....
You said: until the view has been fully rendered (e.g., OnUpdate()).
When are all these functions UpdateData(),GetDlgItem(), fully rendered??
|
|
|
|
|
Overwrite OnInitialUpdate() and call your functions after the base-call.
Greetings from Germany
|
|
|
|
|
Dear KarstenK,
I tried calling OnBconnect() in OnInitialUpdate().....it worked....Thanks
|
|
|
|
|
According to MSDN, the first parameter to CDC::DrawDragRect() is lpRect and it "specifies the logical coordinates of a rectangle"
However, when I pass in a pointer to a rect in logical coordinates, (DC mapping mode not in MM_TEXT) it draws the rect as if it were treating the rect as if it were in device coordinates.
I can draw a "Rectangle()" with the same rect using the same DC and that rectangle comes out as anticipated.
Is there a misprint in the MSDN and should the rect for CDC::DrawDragRect() be in device coordinates?
|
|
|
|
|
CDC::DrawDragRect() uses PatBlt() to draw the drag rect. If you directly call PatBlt() on the DC
do you get the same result as CDC::DrawDragRect()?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Anything I draw explicitly in logical space is coming out fine on my viewport. The mapping mode results are good for general primitives and blitting operations.
It wasn't that I couldn't provide my own implementation for DrawDragRect(), it was just that I was entertaining the idea that I might be missing something obvious as I'd rather use functionality thats already provided so my peers don't crucify me for reinventing the wheel.
I wasn't sure if it was well known that MSDN incorrectly states the word "Logical" or if that in fact is what it's supposed to do and I had something goofy in my code causing me to chase my tail.
Anyway, I'll play with some patterns and see what I get.
Thanks.
|
|
|
|
|
You could step into the call and see what's different than when you draw
it yourself.
I didn't see anything in there that changes the mapping mode but I didn't
do a runtime test.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Hi,
Sorry, but I just began learning C++ (I have better experiences in Java, PHP). Can anyone tell me how I can add GDI+ functionallity to my existing VS2005 C++ based project?
I've already searched for hours and everbody is just telling how to use the Classes right away but is missing the first step... yeah I know, maybe it's to simple, that's way. But I don't know it yet. I tried with adding System.Drawing.dll somehow to the project, but it didn't work.
Thanks in advance
Shi
|
|
|
|
|
I'm not sure about VC++ 2005, but in VC++ 2003...
(NOTE: this assumes native code)
// In stdafx.h
#include <gdiplus.h>
using namespace Gdiplus;
#pragma comment(lib, "GdiPlus")
// Somewhere else in app. Timing is important
// (i.e. don't call too early)
// I usually call it in an MFC app in the
// CDocument constructor with a boolean in
// the app to prevent multiple initialization
// attempts.
// Member in CWinApp or somewhere if not MFC app
ULONG_PTR m_gdiplusToken;
GdiplusStartupInput gdiplusStartupInput; // local variable
if (GdiplusStartup(&m_gdiplusToken,&gdiplusStartupInput,NULL)==Ok) {
// Ready to go
}
|
|
|
|