|
peoria123 wrote: Please help me out I dont understand how i can give filename(with path) from mfceditbrowse (dlg1) to .exe file (dlg2) Separate your problem into two smaller problems. First get the filenames from the various controls. Once you have successfully done that, then worry about passing those names to the EXE.
"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
|
|
|
|
|
how can update .properties file
|
|
|
|
|
Any way you like. Now if you want to give some more detail about your problem people will try to help you.
Use the best guess
|
|
|
|
|
hi,
i need to update .properties file example
log4j.logger.PXPBroker=TRACE, C, fileappender
log4j.additivity.PXPBroker=false
log4j.appender.C=org.apache.log4j.ConsoleAppender
log4j.appender.C.layout=org.apache.log4j.PatternLayout
log4j.appender.fileappender=org.apache.log4j.RollingFileAppender
log4j.appender.fileappender.File=C:/pxpserver/logs/pbesb.log
i want to update these values in c++ please help me.
|
|
|
|
|
Use one of the fstream [^] classes to read the file, change the values that you wish to update, and write the changed values with another fstream object.
Use the best guess
|
|
|
|
|
Apparently MFC has no classes to encapsulate static text or group boxes.
What is the preferred method for resizing them as the user resizes the window?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Your question could do with a bit more detail; what exactly are you trying to do? You can use the CStatic Class[^] for static text, and that is resizable (as is any window).
Use the best guess
|
|
|
|
|
Thanks.
I assumed there was no MFC class because the "Add Variable" wizard did not present me with one.
I've created a small class that automatically resizes and repositions controls when a window is resized, and I inherited from classes liked CComboBox, CListBox but I didn't see the CStatic class.
Thanks again.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Richard Andrew x64 wrote: I assumed Never assume anything with MFC. I have also found in the past that the Wizard does not always list every possibility, even though MFC wraps all the standard Windows and has a number of custom types.
Use the best guess
|
|
|
|
|
This is not a programming "how to", just looking for short explanation/ verification of usage of "moniker".
My basic understanding is that it's function is similar to DOS path, allowing access to an object.
Now it this particular sequence I do not get the enumeration, followed by getting the first moniker and bind it to , I guess filter.
This is part of my code to get data from USB camera and I am still learning how to put all this COM and DirectShow stuff together.
This is what I understand so far – the enumeration identify the “object class” in my case USB cameras and than I can select which one using the Next in loop ( this snippet gets only the first one) and than let the filter “connect / bind “ to the selected camera.
This is still plain COM code , no DirectShow.
Am I right so far?
Thanks for reading.
Cheers Vaclav
TRACE("\nObtain a category enumerator by calling ICreateDevEnum::CreateClassEnumerator with the CLSID of the desired category");
IEnumMoniker* cams = 0;
hr = devs?devs->CreateClassEnumerator (CLSID_VideoInputDeviceCategory, &cams, 0) ;
if (FAILED(hr))
{
TRACE("\nFailed devs->CreateClassEnumerator (CLSID_VideoInputDeviceCategory");
return;
}
ASSERT(cams); // redundant
TRACE("\nget first found capture device (webcam?)");
// moniker - similar to DOS path to get info on object
IMoniker* mon = 0;
hr = cams->Next (1,&mon,0); // get first found capture device (webcam?)
if (FAILED(hr))
{
TRACE("\nFailed get first found capture device (webcam?)");
return;
}
ASSERT( mon);
TRACE("\nBind moniker ( mon) to object ( cam)");
IBaseFilter* cam = 0;
hr = mon->BindToObject(0,0,IID_IBaseFilter, (void**)&cam);
if (FAILED(hr))
{
TRACE("\nFailed Bind moniter ( mon) to object ( cam)");
return;
}
ASSERT( cam);
|
|
|
|
|
Your friend is MSDN
Monikers (COM)
Q. Hey man! have you sorted out the finite soup machine?
A. Why yes, it's celery or tomato.
|
|
|
|
|
"A moniker in COM is not only a way to identify an object—a moniker is <b>also implemented as an object</b>. "
What a startling, useful and unexpected information!( SARCASM)
Seriously, thanks for your reply. It is helpful.
|
|
|
|
|
COM has been evolving since before Windows 3, so there's stuff lingers on because of backward compatibility that won't break existing code.
Q. Hey man! have you sorted out the finite soup machine?
A. Why yes, it's celery or tomato.
|
|
|
|
|
Hey coders,
I came up with a little puzzle/challenge for C++, so for those interested, my challenge to you is this:
Using any C++ constructs, other than any of the casting constructs*, reimplement the following code:
int i = someIntValue();
int *pint = reinterpret_cast<int*>(i)
Or in words, find a way to reinterpret_cast an integer into a pointer without casting (implicitly, or explicitly!). You may assume that sizeof(int)==sizeof(int*) .
I hope to be surprised by answers I hadn't thought of
* with casting constructs, I mean any form of implicit casts (e.g. int to long int), C-style casts (e.g. (int*)i ) and C++-style casts (e.g. reinterpet_cast<int*>(i) ); and also any functions/macro's/API calls (such as STL implementations) which rely internally on casts.
Best Regards,
Richard
|
|
|
|
|
This forum is for serious questions, the Lounge is the place for quizzes.
Use the best guess
|
|
|
|
|
Hmmm Didn't realise that.
I felt it was more in place in a C++ specific message board than in a lounge, as I do find such challenges to be stimulating myself.
|
|
|
|
|
Richard MacCutchan wrote: This forum is for serious questions, the Lounge is the place for quizzes.
I deem this is technically appropriate (by the definitions of the rules), it is C++/C code.
Where in the rules up at the very top posted by Admin Chris Maunder, does it directly say that is for serious questions.
Keep in mind a quiz is a question, you are giving an answer.
EDIT:
Chris Maunder wrote: Please do not post links to your question in one forum from another, unrelated forum (such as the lounge). It will be deleted.
And you said...
Richard MacCutchan wrote: the Lounge is the place for quizzes.
Trying to guide him in the wrong path , consider re-reading the rules.
Simple Thanks and Regards,
Brandon T. H.
Programming in C and C++ now, now developing applications, services and drivers (and maybe some kernel modules...psst kernel-mode drivers...psst).
Many of life's failures are people who did not realize how close they were to success when they gave up. - Thomas Edison
|
|
|
|
|
Brandon-X12000 wrote: I deem this is technically appropriate I suspect you are in a minority.
Brandon-X12000 wrote: Trying to guide him in the wrong path Not at all, the Lounge is the place for such questions; even Chris posts them there.
Use the best guess
|
|
|
|
|
You could do something like:-
int i = 42;
int* pint = 0;
int** ppint = 0;
ppint += &i;
pint = *ppint;
If I'm not mistaken pint is now an int pointer to address 42 and no casting as such has taken place.
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
|
Matthew Faithfull wrote: ppint += &i;
Doesn't work - you only can add integral types (size_t and anything that implicitely converts to size_t ) to a pointer.
Also, as Harold Aptroot pointed out in response to my variant, even if it would work as intended, pint would point to 42*sizeof(int) , not 42 .
|
|
|
|
|
I haven't tried it as it's, as you point out, not of practical use but &i is certainly integral. Another step may be needed to get around restrictions on adding pointers to pointers but the principle is the same. The multiplication by sizeof(int) is not an really issue as this can be overcome without any casting.
The addition was a syntactic nicety to explain what I was doing anyway and is not strictly necessary. How about:-
int i = 42;
int** ppint = &i;
int* pint = *ppint;
which is shorter and doesn't do pointer arithmetic.
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
|
Dear Matthew,
Thanks for submitting your solution. Unfortunately, ppint is of type int**, whereas &i returns an int*, so this will not work without casting int* to int**.
|
|
|
|
|
I would like to see the assmebler generated for the cast from int* to int**. My expectation is that it would consist of 0 instructions or at most a nop. If no actual cast takes place and none is specified in the code then I say the challenge is met. Assignment from int* to int** is certainly valid. In reality at the backend of most compilers I suspect int* and int** will be same thing anyway.
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
|
It's true that in many implementations of C/C++ a pointer to one type is technically (in terms of generated code and storage needs) the same as a pointer to any other type.
But in terms of the language, int* is certainly not an int**. At the very least, the compiler will give you an error on the line int **ppi = &i , saying there is no conversion from int* to int**. But ok, that's the compiler, so maybe it's just being annoying? One nice way, I think, of realising these two (int* and int**) are two very different objects is the following:
int* pi = ...;
int** ppi = ...;
*pi; *ppi; **ppi; **pi;
So I'd say that int* and int** can't be the same thing, because the one can do something the other can't
|
|
|
|
|
int i = someIntValue();
int *pint = 0;
pint += i;
Note that this doesn't even require sizeof(int)==sizeof(int*) , as i will be cast to the correct size implicitely.
|
|
|
|