|
The line
filenames = malloc(n_files * sizeof(char));
should be
filenames = malloc(n_files * sizeof(char *));
because you use it to allocate pointers.
You don't show the declaration of filenames in the sample, but I assume it's char **.
By the way, what happens if a file in the directory has a name longer than 19 characters?
The good thing about pessimism is, that you are always either right or pleasently surprised.
|
|
|
|
|
I think you'll find that the line:
filenames[i]=dird->d_name; should actually be something like:
filenames[i]=strdup(dird->d_name);
You see, dird->d_name is a location in memory that the current file's name is copied to - _but_ this location doesn't change, only the contents of the text does. What your code does is set each of the filename[] elements to hold this location. In the next iteration of the loop, the text contained there changes, but the location doesn't. So you've got all elements of filename[] holding the same address of a string.
If, on the other-hand, you make a duplicate of the string in dird->d_name and then store _that_ location into filenames[], each element of filenames[] will point to a different location in memory - locations that contain the string you're after.
Note - you should also change your last code-block.
filenames = malloc(n_files * sizeof(char*) );
So,
1) filenames should be a char** (I expect you've got it setup to be a char* currently)
2) each element (a char*) should contain the address of the duplicated string
3) No need for the filenames[i] = malloc(20 * sizeof(char) ); code.
|
|
|
|
|
Thank you for the answer.
Of course I declared filenames as char**...  But I didn't know really good how the d_name variable works, then I made some mistakes... Now it's all clearer!
|
|
|
|
|
You're welcome.
I'd hoped you had, though the way you used it gave me the impression it was only a char*
Glad to be of help. 
|
|
|
|
|
I cannot find its implementation anywhere. MSDN is not much of a help.
|
|
|
|
|
The MSDN entry[^] includes a link to a sample implementation.
|
|
|
|
|
Hello
I'm create an IE addon that inject a style sheet to page.
CComBSTR scTagStyle = "STYLE";
IHTMLElement* elementStyle;
HRESULT hr = spHTMLDoc->createElement(scTagStyle, &elementStyle);
IHTMLDOMNode *domStyleNode;
hr = elementStyle->QueryInterface(IID_IHTMLDOMNode, (LPVOID*)&domStyleNode);
IHTMLStyleElement *IstyleElem;
hr = elementStyle->QueryInterface(IID_IHTMLStyleElement, (LPVOID*)&IstyleElem);
I dont know the way to set css_text to IHTMLStyleElement.
Please help me solve this problem.
Regards,
Son Dang
|
|
|
|
|
Hi,
I'm trying to create .zip files within a C# application with the LZMA SDK.
The code worked immediately, but I can't figure out how to produce a .zip output, and I must have plain .zip. The 7z GUI produces .zip files with no problem, so it must be possible with the SDK.
I thought sure that changing the "algorithm" property was the answer, but running tests with that property ranging from 0 to 8 produced no apparent change in the output. Windows Explorer (7) rejects all such efforts, while the 7z GUI opens the outputs, no matter what.
I've spent too much time perusing the C++ source code for the GUI. It's obvious that the author has a command of C++ that's an order of magnitude greater than mine.
In short, what property need I set to what to yield a .zip output?
Thank you.
John
|
|
|
|
|
Shouldn't you rather be looking for an answer here[^]?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
Yes, that's where I started.
|
|
|
|
|
I think you're getting confused between two different things. 7-Zip is an application that can compress and decompress several types of file, whereas the LZMA SDK is for compressing and decompressing using the LZMA algorithm.
If all you want to do is create ZIP files, then zlib would probably be a better option: http://www.zlib.net/[^] or maybe system.io.compression.zipfile[^] since you're using C#.
|
|
|
|
|
LZMA SDK Copyright (C) 1999-2007 Igor Pavlov
LZMA is default and general compression method of 7z format
in 7-Zip compression program (www.7-zip.org). LZMA provides high
compression ratio and very fast decompression.
-----------------------
It doesn't mention .zip, or the other compression schemes 7 Zip handles, as coming out of LZMA, does it?
Sorry I bothered you.
John
|
|
|
|
|
Like most of these zip programs you can change the compression format off the command line.
So set a command line on your compiler and follow it. The documentation to Z-Zip says
Type switches
Switch: -t7z
Format: 7Z
Example filename: archive.7z (default option)
Switch: -tgzip
Format: GZIP
Example filename: archive.gzip, archive.gz
Switch: -tzip
Format: ZIP
Example filename: archive.zip (compatible)
Switch: -tbzip2
Format: BZIP2
Example filename: archive.bzip2
Switch: -ttar
Format: TAR
Example filename: tarball.tar (UNIX and Linux)
Switch: -tiso
Format: ISO
Example filename: image.iso (may not be supported)
Switch: -tudf
Format: UDF
Example filename: disk.udf
So setup a command line to some file with -tZip and follow what it does.
In vino veritas
|
|
|
|
|
Actually what iam doing now means i created one dialog on that iam drawing a image everything is working fine but its flickering continuously.so now my idea was without dialog i want to save that drawing part in memory so that it can be used for showing the report.
modified 15-May-14 5:03am.
|
|
|
|
|
What? Could you please elaborate a bit your scenario?
Veni, vidi, vici.
|
|
|
|
|
You have to be more specific. What does a dialog have to do with how you save an image? And what do you mean by saving the image directly in memory?
|
|
|
|
|
What image and where are you trying to save it?
|
|
|
|
|
|
|
I'm trying to derive from CMFCPropertyGridColorProperty and cannot override the virtual function because my derived class is not a friend of CMFCPropertyGridCtrl.
Here is a minimal representation of the problem.
class CMFCPropertyGridCtrl
{
friend class CMFCPropertyGridColorProperty;
protected:
CRect m_rectList; };
class CMFCPropertyGridColorProperty
{
friend class CMFCPropertyGridCtrl;
public:
virtual void AdjustInPlaceEditRect(CRect& rectEdit, CRect& rectSpin);
protected:
CMFCPropertyGridCtrl* m_pWndList;
};
void CMFCPropertyGridColorProperty::AdjustInPlaceEditRect(CRect& rectEdit, CRect& rectSpin)
{
m_pWndList->m_rectList.left += 20;
}
class MyPropertyGrid : public CMFCPropertyGridColorProperty
{
virtual void AdjustInPlaceEditRect(CRect& rectEdit, CRect& rectSpin);
};
void MyPropertyGrid::AdjustInPlaceEditRect(CRect& rectEdit, CRect& rectSpin)
{
m_pWndList->m_rectList.left += 40; }
trying to compile this, I get the following understandable error :
error C2248: 'CMFCPropertyGridCtrl::m_rectList' : cannot access protected member declared in class 'CMFCPropertyGridCtrl'
1> d:\projects\testfriend\testfriend\testfriend.cpp(21) : see declaration of 'CMFCPropertyGridCtrl::m_rectList'
1> d:\projects\testfriend\testfriend\testfriend.cpp(17) : see declaration of 'CMFCPropertyGridCtrl'
---
I'd like to be able to override the method
virtual void AdjustInPlaceEditRect(CRect& rectEdit, CRect& rectSpin);
void CMFCPropertyGridColorProperty::AdjustInPlaceEditRect(CRect& rectEdit, CRect& rectSpin)
{
ASSERT_VALID(this);
ASSERT_VALID(m_pWndList);
rectSpin.SetRectEmpty();
rectEdit = m_Rect;
rectEdit.DeflateRect(0, 2);
int nMargin = m_pWndList->m_bMarkModifiedProperties && m_bIsModified ? m_pWndList->m_nBoldEditLeftMargin : m_pWndList->m_nEditLeftMargin;
rectEdit.left = m_pWndList->m_rectList.left + m_pWndList->m_nLeftColumnWidth + m_Rect.Height() + AFX_TEXT_MARGIN - nMargin + 1;
AdjustButtonRect();
rectEdit.right = m_rectButton.left;
}
To change the edit box position in the CMFCPropertyGridColorProperty class; but since I do not have access to the CMFCPropertyGridCtrl class (via m_pWndList), I cannot really override it.
Any hints/tips or something else that I might have missed?
Thanks.
Max.
I'd rather be phishing!
|
|
|
|
|
Why don't you inherit from both classes?
Veni, vidi, vici.
|
|
|
|
|
YUCK!!!
A colleague offered the same suggestion.
I tried and it works... but I do not really like it.
I'd rather be phishing!
|
|
|
|
|
Maximilien wrote: I tried and it works... but I do not really like it.
You will love multiple inheritance. 
Veni, vidi, vici.
|
|
|
|
|
Yeah, but ultimately it does not work.
I cannot inherit from both CMFCPropertyGridColorProperty and CMFCPropertyGridCtrl.
The CMFCPropertyGridCtrl is a UI container class containing instances of CMFCPropertyGridProperty.
the CMFCPropertyGridCtrl is constructed before the CMFCPropertyGridProperty are constructed; and if I multiple inherit from CMFCPropertyGridCtrl , there will be 2 "instances" of the class and there should be only one.
I'm still working on something.
I'd rather be phishing!
|
|
|
|
|
You could make a class inheriting from CMFCPropertyGridCtrl, say MaximilenMFCPropertyGridCtrl which only purpose is being a good friend of MyPropertyGrid.
Veni, vidi, vici.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
