|
big_denny_200 wrote: sPath.GetBuffer(0)
Getting Zero characters.
sPath.GetBuffer(sPath.GetLength())
"What classes are you using ? You shouldn't call stuff if you have no idea what it does" Christian Graus in the C# forum
led mike
|
|
|
|
|
(Dumb statment due to brain freeze removed.)
Since the second parameter to fopen_s is a const char* , you can simply do:
if (0 != fopen_s(&pFile, sPath, "w+b"))
To be more picky; since you are using the _T macros, the proper code should be:
if (0 != _tfopen_s(&pFile, sPath, _T("w+b")))
EDIT:
To be even more picky; CString indicates you are using MFC, so why not use the CStdioFile class?
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
-- modified at 14:04 Monday 15th May, 2006
|
|
|
|
|
thanks for reply.
What does it mean clearing buffer ?
I thought I was getting const pointer to wchar_t of sPath variable and then was casting it to const char * .
Was I wrong ?
I wanted to read(write) file data, per n bytes(first n bytes then second n bytes,..)
I thought using FILE would be good solution. As I would call fread() metod in loop.
Do you think using CFile is better ? in this case I will have to use Seek() methods.
Or better CStdioFile ?
thanks
-- modified at 14:08 Monday 15th May, 2006
|
|
|
|
|
I had a temporary brain freeze and mispoke; CString::GetBuffer returns a non-const pointer to memory with length at least that passed. Since you then cast it to a const pointer, the first call should have worked. It may have failed because the file was already open and locked or some other reason unrelated to the actual call.
(You should still just have passed sPath as the second parameter.)
If you are reading small amounts of data, the FILE based functions are a good way since they cache the reads/writes. CStdioFile encapsulates these functions.
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
Joe Woodbury wrote: I had a temporary brain freeze and mispoke;
why ?
Joe Woodbury wrote: CStdioFile encapsulates these functions
I am sorry for being so silly but I do not really fully understand meaning of word encapsulate.
Thank's for your attention.
|
|
|
|
|
big_denny_200 wrote: ...I do not really fully understand meaning of word encapsulate.
Wraps 'em up in a nice little package[^]
"The largest fire starts but with the smallest spark." - David Crow
|
|
|
|
|
big_denny_200 wrote: Joe Woodbury wrote:
I had a temporary brain freeze and mispoke;
why ?
GetBuffer() returns a pointer to a buffer of at least n characters long; it does not truncate that buffer if the passed value is less than the currently allocated buffer.
Still you should only call CString::GetBuffer() when you need to directly modify the contents of the string.
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
big_denny_200 wrote: if( 0 != fopen_s( &pFile,(LPCSTR)sPath.GetBuffer(0),"w+b") )
The call to GetBuffer() is not necessary.
if (0 != fopen_s(&pFile, (LPCSTR) sPath, _T("w+b")))
"The largest fire starts but with the smallest spark." - David Crow
|
|
|
|
|
then i get error :
Error 1 error C2440: 'type cast' : cannot convert from 'CString' to 'LPCSTR'
|
|
|
|
|
Just realized that you are compiling in UNICODE but using the MBCS version of the function.
The proper code should read:
if (0 != _tfopen_s(&pFile, sPath, _T("w+b")))
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
Neither is the cast. The problem is, I finally realized, is that he is compiling in UNICODE but using the MBCS version of the function.
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
Joe Woodbury wrote: Neither is the cast.
I don't know the parameter list for fopen_s() so I wasn't for sure if it would be required or not. I errored on the side of caution.
"The largest fire starts but with the smallest spark." - David Crow
|
|
|
|
|
|
Hello.
I've looked all over the place, but I can't find a function that you can give a shell command, have it execute it, and then return the results of the shell command to you as a string. Is there such a command, and if so, what is it?
Actually i wanna code a server to receive command from a remote client then process it and send result.but i dont know how can i work with command and send the result through socket.for example when u wanna see a list of files in dir how u can send the list using socket.should i change it to string?is it a kind of pipe?
Thanks,
f.f
-- modified at 11:24 Monday 15th May, 2006
|
|
|
|
|
See here and here.
"The largest fire starts with but the smallest spark." - David Crow
|
|
|
|
|
You can always "pipe" any output from command line to a filepath, e.g. "dir < COM1".
If you don't tell where to put the output from a command line executed program, it will usually use STDOUT, which is usually the screen.
STDOUT is a file pointer that is constant, i.e. you cannot change its value. You can, however, redirect the information written to STDOUT to another "file" using freopen().
I don't know much about your needs and what's suitable for you, but I would try creating a named pipe and either "pipe" the program output to that pipe with command line arguments, or try to redirect STDOUT to the named pipe.
Hope this helps
--
Roger
It's supposed to be hard, otherwise anybody could do it!
Regarding CodeProject: "resistance is pointless; you will be assimilated"
|
|
|
|
|
My recent work content involved some exception handling, __try/__except to be specific. And the following is the questions that confused me.
int filter()
{
puts("Filter()");
return EXCEPTION_EXECUTE_HANDLER;
}
int _tmain(int argc, _TCHAR* argv[])
{
int a = 1;
int *p = NULL;
char s[10];
__try
{
__try
{
a = 2;
*p = a;
puts("After exception raised");
a = 3;
}
__finally
{
puts("Finally");
a = 4;
}
}
__except(filter())
{
puts("_except");
a = 5;
}
sprintf(s, "%d", a);
puts(s);
_getch();
return 0;
}
My questions focused on the return statement in exception filter function:
if it is return EXCEPTION_EXECUTE_HANDLER ,why the statement a = 3; never gets excuted?
if it is return EXCEPTION_CONTINUE_EXECUTION ,why the filter keeps getting called. according to MSDN EXCEPTION_CONTINUE_EXECUTION The system stops its search for a handler and returns control to the point at which the exception occurred.return control to *p = a ? only to cause another same exception? what's the point here?
if it is return EXCEPTION_CONTINUE_SEARCH , the system keeps searching for exception handlers on and on and on for access violation? until the handlers were exhausted? another seemingly endless function call?
|
|
|
|
|
LiYS wrote: if it is return EXCEPTION_EXECUTE_HANDLER,why the statement a = 3; never gets excuted?
A quote from MSDN: "A __finally statement does not block searching for an appropriate exception handler". You raise the exception with the following statement:
*p = a;
The system will then looks for an exception handler calling any __finally blocks on the way (actually this isn't quite true but it's good enough for now). When it gets to the __except block the filter expression returns EXCEPTION_EXECUTE_HANDLER so it enters the block and the exception is handled.
LiYS wrote: if it is return EXCEPTION_CONTINUE_EXECUTION,why the filter keeps getting called.
The idea of EXCEPTION_CONTINUE_EXECUTION is that the code first takes some action to correct the problem then execution is resumed and the operation is retried: you are performing no such correction thus the problem keeps recurring. In short everything is working as it should. Note that the __finally handler will not be called in this case (this is where real life differs slightly from my explaination as alluded to in my, "this isn't quite true" comment above).
LiYS wrote: If it is return EXCEPTION_CONTINUE_SEARCH, the system keeps searching for exception handlers on and on and on for access violation?
If you return this you're telling the system that the particular __except block should not be entered and to continue searching for a handler. If no handler is encountered that handles the exception execution is aborted.
Steve
|
|
|
|
|
Hi all,
Are you concentrating?
Yes, good!
Please read this carefully
An example of my problem is I have three controls.
- Control A
- Control B1
- Control B2
I want to be able to either B1 or B2 to be a child window of A depending on how I set the properties. Of course I know A is child window. when I place it on the a driver (demo) app, it crashing my system. I want to know to do this safely?
Many thanks,
alton
|
|
|
|
|
Hi Alton!
If you find the part below hard to understand, please let me know and I'll repost typing it slower.
Alton Williams wrote: Of course I know A is child window. when I place it on the a driver (demo) app, it crashing my system.
How does it crash your system? Error messages? Some info from debug sessions?
The "system" could crash from a zillion reasons, give or take a few, it's quite hard to guess what your problem is.
--
Roger
It's supposed to be hard, otherwise anybody could do it!
Regarding CodeProject: "resistance is pointless; you will be assimilated"
|
|
|
|
|
Hi Roger,
Thanks for your prompt reply!
Roger Stoltz wrote: How does it crash your system? Error messages? Some info from debug sessions?
When I build and register the control. When I place it on another form (in VB) or Dialogue box (in VC++) for testing. it seems to bring down VB or VC++. If I'm lucky if my final app comes down or doesn't respond at run-time.
Is that any clearer?
Alton
|
|
|
|
|
Alton Williams wrote: When I build and register the control.
I interpret this as you get an assertion or runtime error when you try to register the component after a successful build. Correct?
What happens if you try to register the component outside DevStudio? If it crashes even then I suggest you try to debug the component by selecting RegSvr32.exe as the executable for debug session, provide the complete path to your debug-built component as argument and "run" your component (F5). Put a breakpoint inside DllRegisterServer() and step through the registration call chain.
If you don't get any clues from this exercise; post again and describe what happens, what error messages you're getting and where.
Alton Williams wrote: When I place it on another form (in VB) or Dialogue box (in VC++) for testing. it seems to bring down VB or VC++. If I'm lucky if my final app comes down or doesn't respond at run-time.
If the registration isn't successful you may get various errors when you try to use the component, e.g. inserting it to a client or running the final app.
In other words: let's fix the registration first if it doesn't work.
--
Roger
It's supposed to be hard, otherwise anybody could do it!
Regarding CodeProject: "resistance is pointless; you will be assimilated"
|
|
|
|
|
Hello Roger,
Sorry I've a while to answer your question
Roger Stoltz wrote: Alton Williams wrote:
When I build and register the control.
I interpret this as you get an assertion or runtime error when you try to register the component after a successful build. Correct?
No, Rog! It builds and get registered perfectly when I place the end result onto another project be it VC dialogue or a VB form the aproppriate developer app (MSVC6 or MSVB6) crashes. I if it would be a HWND problem
I'll explain the issue more clearly.
I've created three controls;
- A control called child1ctrl which is a subclass of "EDIT"
- Another called child2ctrl is that of "STATIC"
- A third one called holderctrl which isn't subclassed
Firstly, I design controls 1 & 2 individually either as single project or two projects (that's not relevant). Naturally it builds and registers the two controls ok. At this stage when add either (1 or 2) to other projects. Works perfectly.
It's when I am design control no 3. I'm what is the cause for concern
I do the follow
- I go through the wizard
- I add controls (1 and 2) to the project and it generates the wrapper
classes.(CChild1 & CChild2) - I make these as two member variables one of each class.
- I write code to create the two child windows
I have no problems with build and the control registers with no problems. Its when I add HolderControl onto other projects I drag and drop it on a diaglogue box and crashes VC++ (msdev.exe). Likewise I do it on a for VB (VB.exe) comes down.
To begin with I wrongfully wrote code to create (1 & 2) in WM_CREATE.
class CHolder{
virtual void PreSubclassWindow();
private:
CChild1 m_ctrl1;
CChild2 m_ctrl2;
BOOL m_bFlag
Then
void CHolderCtrl::PreSubclassWindow()
{
m_bFlag = m_ctrl1.CreateControl(clsid, NULL, dwStyle, rect, this)
&& m_ctrl2.CreateControl(clsid, NULL, dwStyle, rect, this);
COleControl::PreSubclassWindow();
}
On debugging what is causing the crashing seems lie with the first call to create for the first "window" so the second call doesn't happen.
MS Calendar Control 8.0 dosen't behave like this. I has two child ComboBoxes and 50 Statics on it.
I don't if I'm clearer now.
I going to repost the question on this an other forums, until I get an answer.
Thanks for your help nonetheless.
Alton
|
|
|
|
|
Alton Williams wrote: On debugging what is causing the crashing seems lie with the first call to create for the first "window"
Seriously Alton, you have to investigate your own code better than that or no one will ever bother to answer your vague question.
It's perfectly allright to have an ActiveX control as a container for another ActiveX control, you don't have to doubt that.
The reason why this doesn't work in your code is because you've either removed some important stuff or haven't written the important stuff yet.
It's also not very clear what base classes you're subclassing from or why. If you're using MFC to create your controls, the only class you should derive from is COleControl; anything else I would consider highly suspicious and to be removed at once if not given a lot of thought ending with "I've-read-alot-about-it-and-I-know-it's-the-correct-way-to-do-it".
I suggest you start over with the CHolderCtrl and create it with the ActiveX control wizard.
For every step you take building the functionality of the CHolderCtrl, you should test it with "ActiveX Control Test Container" that ships with MSVC.
Don't add the two contained ActiveX controls to CHolderCtrl until the last step. Make sure they can be inserted in an ordinary ActiveX control container before attempting to add them to CHolderCtrl.
Alton Williams wrote: Its when I add HolderControl onto other projects I drag and drop it on a diaglogue box and crashes VC++
This feels like the ActiveX control hasn't got all the required interfaces implemented as needed for it to an ActiveX control container.
Have a look here[^] for required interfaces depending on what functionality you want to support.
Alton Williams wrote: MS Calendar Control 8.0 dosen't behave like this. I has two child ComboBoxes and 50 Statics on it.
Now, this sentence really disturbs me since it makes me wonder if you're under the impression that comboboxes, edit and static controls are ActiveX controls.
Just to tie up loose ends: comboboxes and static controls are not ActiveX controls!
On the other hand, perhaps this is exactly what you're after; an ActiveX control that looks like a dialog (or similar) with some CEdit/CStatic controls within the window....
If this is the case, you should have a member variable for each control on your window and simply call e.g. CEdit::Create() when you want to create a CEdit control.
Alton Williams wrote: I going to repost the question on this an other forums, until I get an answer
Well, perhaps not this question, you should investigate your code further and be more precise. But by all means: repost and you might get more replies since this thread is old and probably won't be read by anyone but me.
Alton Williams wrote: Thanks for your help nonetheless
You're welcome!
--
Roger
It's supposed to be hard, otherwise anybody could do it!
Regarding CodeProject: "resistance is pointless; you will be assimilated"
|
|
|
|
|
I want to reproduce the sliding creation effect of a Window. The Window should slide when it is visible. I mean, first 10% of the width of the window should be visible, then 20% and so on. This must have a sliding effect. I have achieved it through by using regions. I am posting the code here. Can anyone suggest a better way?
The code is modified from Jaime Olivares' [^] article on Appbars.
void SlideWindow(CPoint StartPoint, BOOL Right2Left)<br />
{<br />
int nWinWidth = 500 ;<br />
int nWinHeight = 100 ;<br />
unsigned int t; <br />
int x ;<br />
int maxdelay = 5; <br />
float step = nWinWidth / 10.0f; <br />
HRGN hRgn ;<br />
SetWindowPos(HWND_TOP, StartPoint.x, StartPoint.y ,nWinWidth, nWinHeight, 0) ;<br />
<br />
for (int i=0, delay=maxdelay; i<=10; i++, delay+=2) <br />
{<br />
t = ::GetTickCount() + delay;
x = StartPoint.x - (int)(i*step) * (Right2Left?1:-1);
if(Right2Left)<br />
{<br />
hRgn = CreateRectRgn(0, 0, (int)(i*step), nWinHeight) ;<br />
SetWindowRgn(hRgn , FALSE ) ;<br />
DeleteObject( hRgn ) ;<br />
hRgn = NULL ;<br />
}<br />
else<br />
{<br />
hRgn = CreateRectRgn(0, 0, nWinWidth - (int)(i*step), nWinHeight) ;<br />
SetWindowRgn(hRgn , TRUE ) ;<br />
DeleteObject( hRgn ) ;<br />
hRgn = NULL ;<br />
} <br />
SetWindowPos(HWND_TOP, x, StartPoint.y, nWinWidth, nWinHeight, SWP_SHOWWINDOW);
<br />
while (::GetTickCount()<t)
::Sleep(15); <br />
}
---
With best regards,
A Manchester United Fan
The Genius of a true fool is that he can mess up a foolproof plan!
|
|
|
|
|