|
Using C++? #import the Excel type library (as shown here[^]), then use the Excel object model to do whatever you want.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Hi,
Is there any way to store the output of CreateProcess("C:\\Windows\\System32\\cmd.exe", command, NULL, NULL, 0, 0, NULL, NULL, &si, &pi); .so that it can be stored in an array.Basically i want to say that if in command i put /K dir then it will show all the directories but i want to store that name of directories or whatever which is output in an array. Is it possible?
|
|
|
|
|
ravi 12 wrote: .Basically i want to say that if in command i put /K dir then it will show all the directories but i want to store that name of directories or whatever which is output in an array.
You can actually get the list of files/folders in a folder using the FindFirstFile(), FindNextFile() functions. The method of using "dir" command to get the list of file doesn't seems good.
|
|
|
|
|
hey naveen,actually i want to see all the directories of all drives.can FindFirstFile() and FindNextFile() functions are able to show me the directories? can you please write down the source code?
|
|
|
|
|
ravi 12 wrote: hey naveen,actually i want to see all the directories of all drives.can FindFirstFile() and FindNextFile() functions are able to show me the directories
yes
ravi 12 wrote: can you please write down the source code?
Sorry. But there are lots of sample. Search google and code project for samples
|
|
|
|
|
ravi 12 wrote: i want to store that name of directories or whatever which is output in an array
So that's what all these threads about launching a new console with CreateProcess, running "dir", and redirecting the output were about?
I believe David Crow was the one with the best mind reading abilities right from the beginning when he suggested (twice) FindFirstFile()/FindNextFile() but you simply ignored that.
Since you're ignoring all suggestions - we can't help you.
|
|
|
|
|
hay Michael Schubert, actually at that time i didn't know anything about FindFirstFile() and FindNextFile() function() .so i was ignoring all those suggestions.
|
|
|
|
|
ravi 12 wrote: so i was ignoring all those suggestions.
Please note: people here make suggestions to try and help you, not for fun. Don't just ignore them and keep repeating your question, but give them a try. Read the documentation on MSDN, use Google to search for help, try the tutorials here on Code Project. Above all try and learn for yourself how to use the many tools that are available to solve your problems.
|
|
|
|
|
Hey Richard MacCutchan, sorry if my words "So i was ignoring all those suggestions" hurt you.Actually at that time i didn't know anything about the function FindFirstFile().I'm sorry for that.Don't mind these words.
|
|
|
|
|
ravi 12 wrote: sorry if my words "So i was ignoring all those suggestions" hurt you.
Ravi, don't worry, your words had no effect on me. I was merely trying to get you to see that when people here make a suggestion, then you should investigate it. It is made to help you get your job done.
|
|
|
|
|
Hi,
I have a Utility, written many years ago. It's main interface consists of a Dialog box with some Text, and Bitmap features. It worked without fault from Win98 upto XP. However, under VISTA, the Bitmaps display at about 2/3 of their design size.Anybody Any Idea why ?
Regards,
Bram van Kampen
|
|
|
|
|
Is the image placed on a static control using the SS_CENTERIMAGE style? The style used to fill uncovered areas of the control with the colour of the top left pixel in the image (a very nice feature btw) but that got changed in windows vista. The docs[^] say it got changed in XP but my apps still run the old behavior in XP but not in vista.
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good - Use it!
|
|
|
|
|
Thanks,
No, this styleflag was not set.
It appears in general that my underlying code works under Vista, but, the carefully crafted Dialog Layouts break down. For starters, Bitmaps display at 2/3rd of their size. Listbox Geometry seems to reduce by a similar factor, the List goes On. What has changed that worked perfectly since Win95. Why was there a need to change.
Regards,
Bram van Kampen
|
|
|
|
|
Hi,
I am developing a desktop application composed by the main exe and several modules (dll / plug-ins) .
The main modules has a dialog where a CMFCPropertyGridCtrl is used to edit a collection of name/values pair.
Also another dll has a wizard that make use of a property sheet where a CMFCPropertygridCtrl edits another collection of name/values pair.
The application works as expected if only one of these dialog is executed.
No matter what is the sequence, the second time the dialog is opened, the program asserts.
I can open the same dialog more times, and it do not asserts, it asserts only when the second kind of dialog is opened.
The dialog (both) asserts when the mouse pointer is passed over the CMFCPropertyGridCtrl Control, the stack traces from the TrackToolTip function inside the class.
I have tracked the problem to the creation of the tooltip window:
in CMFCPropertyGridCtrl::Init() the call to m_IPToolTip.Create(this) fails:
BOOL CMFCPropertyGridToolTipCtrl::Create(CWnd* pWndParent)
{
ASSERT_VALID(pWndParent);
m_pWndParent = pWndParent;
if (m_strClassName.IsEmpty())
{
m_strClassName = ::AfxRegisterWndClass(CS_SAVEBITS, ::LoadCursor(NULL, IDC_ARROW), (HBRUSH)(COLOR_BTNFACE + 1));
}
return CreateEx(0, m_strClassName, _T(""), WS_POPUP, 0, 0, 0, 0, pWndParent->GetSafeHwnd(), (HMENU) NULL);
}
The first time this function executes, the CreateEx return TRUE and all works as expected.
The second time, only if from a different module (DLL or EXE), m_strClassName is not empty and CreateEx fails with error code 0x00057f e.g. "Warning: Window creation failed: GetLastError returns 0x0000057F" that is ERROR_CANNOT_FIND_WND_CLASS.
I do not use any tooltip, so I could also disable the tooltip feature.
(stack trace of the assertion, when the mouse passes over the grid (WM_MOVE) )
mfc90ud.dll!CWnd::GetWindowRect(tagRECT * lpRect=0x0012f06c) Riga 116 + 0x2a byte C++
mfc90ud.dll!CMFCPropertyGridCtrl::TrackToolTip(CPoint point={...}) Riga 3321 C++
mfc90ud.dll!CMFCPropertyGridCtrl::PreTranslateMessage(tagMSG * pMsg=0x00154e10) Riga 3937 C++
> mfc90ud.dll!CWnd::WalkPreTranslateTree(HWND__ * hWndStop=0x003e0662, tagMSG * pMsg=0x00154e10) Riga 2946 + 0x14 byte C++
mfc90ud.dll!AfxInternalPreTranslateMessage(tagMSG * pMsg=0x00154e10) Riga 233 + 0x12 byte C++
did someone experienced something similar? Am I missing something?
Thank you in advance.
Regards
ing. Federico Fuga
|
|
|
|
|
You do not need to perform the check -
if (m_strClassName.IsEmpty())
AfxRegisterWndClass[^] will only register similar classes once.
Read the remarks section of the documentation.
Here is an excerpt from the documentation -
If you call AfxRegisterWndClass multiple times with identical parameters, it only registers a class on the first call. Subsequent calls to AfxRegisterWndClass with identical parameters simply return the already-registered classname.
«_Superman_»
I love work. It gives me something to do between weekends.
Microsoft MVP (Visual C++)
|
|
|
|
|
«_Superman_» wrote: You do not need to perform the check -
if (m_strClassName.IsEmpty())
Hi _Superman_, thank you for your response.
Yes, I know that check is useless, but it's not my code: as you can see, it's the source code of the CMFCPropertyGridCtrl class, in the Visual Studio 2008 MFC Feature Pack.
I should try to remove that check -- m_strClassName is a static member, so it's shared between DLL and EXE; maybe the registration of the control depends on the hInstance of the module calling the Create() function, so it's failing on the second call because it has been registered from another instance.
But this requires to recompile all the MFC / feature pack...?
Note that calling Create() from a third DLL do not solve the issue.
Thank you again
|
|
|
|
|
No No No....
Please do not compile the MFC code.
I didn't realize it was in the MFC code base.
MFC code is properly tested.
The problem could be else where.
Are you able to debug and reach the problem?
«_Superman_»
I love work. It gives me something to do between weekends.
Microsoft MVP (Visual C++)
|
|
|
|
|
No problem, I wasn't thinking that recompiling the MFC would solve the issue
The good news is that I have built a setup package using inno setup, and when installing on a plain Windows XP HE box the latest x86redist package downloaded from microsoft, the application works correctly.
The bad news is that I do not know why. The "working" mfc package has version number 9.0.30729.1, the package installed on my development box (and crashing) has the 9.0.30729.4148. This one seems to be an updated version, dated july 2009 (the working one is dated 2008).
I frankly expected that the older one was on my development box...
So the question is: the most updated library do not work because something has been broken in the library itself, or did I made some mistake on my application?
Any comment?
Thank you again
Federico
|
|
|
|
|
f.fuga wrote: So the question is: the most updated library do not work because something has been broken in the library itself, or did I made some mistake on my application?
It is highly unlikely that the library is broken.
It should be some problem with your application.
You should try and debug it.
«_Superman_»
I love work. It gives me something to do between weekends.
Microsoft MVP (Visual C++)
|
|
|
|
|
«_Superman_» wrote: It is highly unlikely that the library is broken.
It should be some problem with your application.
You should try and debug it.
I agree with you.
I have checked the libraries version, both release and debug are ok.
I think that Release version of my program works as expected because, of course, ASSERT() has only means when compiling in debug mode.
From a practical approach, I should ignore the problem - the Release works. But I suspect that I will find again this problem in the future.
So I will keep search for a solution.
Do you know any issue when using some MFC classes from DLL and EXE ? I know the "AFX_MANAGE_STATE(AfxGetStaticModuleState());" call needed when accessing resources, I suspect a similar problem...
Thank you
Federico
|
|
|
|
|
Hey,
I encountered the exactly same problem while working with CMFCPropertyGridCtrl in my DLL project.
After many trial, i found a way to use CMFCPropertyGridCtrl in DLL without this error.
All you have to do is Create a derived class of CMFCPropertyGridToolTipCtrl(),Make its protected static variable "m_strClassName" NULL in Constructor.
for example;
//////////////////////////////////////////////////////////////////////////////////
Class CMyToolTipCtrl::CMFCPropertyGridToolTipCtrl();
CMyToolTipCtrl::CMyToolTipCtrl()
{
m_strClassName = "";
}
///////////////////////////////////////////////////////////////////////////////////
Now create ToolTipctrl from your CMFCPropertyGridToolTipCtrl() derived class on Init of the CMFCPropertyGridCtrl derived Class.
for example,
///////////////////////////////////////////////////////////////////////////////////
Class MyPropertyGridCtrl::CMFCPropertyGridCtrl();
void MyPropertyGridCtrl::Init()
{
CMyToolTipCtrl p_tooltip;
p_tooltip.Create(this);
}
//////////////////////////////////////////////////////////////////////////////////////
There is always a way.
Priyanka Oza.
|
|
|
|
|
I have some code that has just recently started to 'fail'. I suspect that as long the method StdioFile::ReadString(CString&) would remove both a carriage return and linefeed pair, the code would work fine. I've been through the documentation on MSDN and through the MFC code and it seems that even though the method will 'break' on a carriage return linefeed pair, it will only remove the linefeed character from the string before it is returned. Does anyone know if this is a change that's documented somewhere. Thanks.
Chris Meech
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
|
|
|
|
|
I know that in UNICODE builds, this is a problem when reading UTF16 files. A fix is to open the file in binary mode, and strip the carriage return off the incoming string. I do not know where the docs say so though, but a quick search of "CStdioFile ReadString Unicode" will return lots of discussions on the issue.
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good - Use it!
|
|
|
|
|
Thanks for the help, PJ. This is one of those problems that comes along at the end of the day when the brain's function at a little lower level than normal. This morning, I did some more research and found that the cr/lf pair translation only occurs if the file is opened in text mode. It turns out that a change in our class library, ironically to assist with handling UTF16 type files, changed the default opening mode from type text to type binary and that's causing the issue.
Appreciate the response.
Chris Meech
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
|
|
|
|
|
Hello.
CDC *pDC = GetDC();
CDC tmpDC;
BOOL bRet=tmpDC.CreateCompatibleDC( pDC ); //bRet is 1 => it means succes.
CBitmap m_bmp;
bRet= m_bmp.CreateCompatibleBitmap( pDC, rect.Width(), rect.Height() );
//bRet is 0 ==>it is an error.
DWORD err=GetLastError(); //err is 8. --> it is an error.
error code 8 means : "Not enough storage is available to process this command. "
here, my hdd is 50M remains, and I have enough space fo runing some program...
Why, CreateCompatibleDC() return error code 8?
my System is abnormal?
Thanks.
|
|
|
|