|
Does anyone know where to find an implementation in C of the BDD? Or an algorithm not so criptical. Or maybe someone has something like that.
|
|
|
|
|
Take a look at Fabio Somenzi's website http://vlsi.colorado.edu/~fabio/CUDD/. His Cudd Package is quite famous in the VLSI research cycles. I have used it for about 5 years now.
There is no simple algorithm when it comes to BDDs. People spend years of research on BDD algorithms. I worked with BDDs for five years and unless you are involved strictly with BDDs it is nearly impossible to implement your own algorithms. Just take a look at the source code of Somenzi's package and you will understand.
Time is the fire in which we burn.
|
|
|
|
|
I know about CUDD. As for understanding enough about BDD to make your own algorithm...it's been almost six months since I've started to learn about BDD and still I'm not able to do it.
I guess I'll just try to reduce my expresions by "hand".
Thanks.
|
|
|
|
|
I have a text file where the contents are written all in 2 very long lines. My C++ program looks through it searching for an occurance of a certain string. However, my program says that it never finds that string, even though I know that there are several occurances of it (I checked the file), I know the file is in unicode, and my program is set to work with unicode with a _T() macro used to declare the string. I also told my program to look for another string, which it finds one occurance of (even though there are also several of them). Now, I suspect this might have something to do with how the CString::Find works. I read the file by lines into a buffer using CStdioFile::ReadString, then I have several if statements, the first asking if file.Find(string2) != -1 && file.Find(string1) == -1, the second if file.Find(string1) != -1 && file.Find(string2) == -1, the third if file.Find(string2) < file.Find(string1) and last if file.Find(string1) < file.Find(string2). The only thing I can think of that could be preventing my program from finding all instances of these strings is if CString::Find keeps track of where it left off. So for example if the string is _T("dog, cat, mouse") and I used string.Find(_T("cat")), then the pointer is set after the car and I can no longer search for string.Find(_T("dog"))? Can someone tell me if this is indeed the case, and if not suggest something else that could be causing this. Thanks.
|
|
|
|
|
woooow, is your "Return" keyboard key broken ?
thanks to you dare putting some punctuation... 
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
|
Anonymous wrote:
it finds one occurance of (even though there are also several of them).
Be aware that CString::Find only searches for the _first_ occurence of the substring, so you need to shrink the searched string (file in your example) after having found the first occurence. Could you post some more code ?
Anonymous wrote:
even though I know that there are several occurances of it (I checked the file),
And did you check the string you have read in with the debugger ?
~RaGE();
|
|
|
|
|
Anonymous wrote:
...my program is set to work with unicode with a _T() macro used to declare the string.
Which means nothing if you have not defined UNICODE and _UNICODE.
Anonymous wrote:
Can someone tell me if this is indeed the case...
No, that is not the case, unless you explicitly supply a second parameter.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Hello,
In the InitInstance of my CWinApp, I simply create an CPropertyPage by
just simply
CPropertyPage p(SOME_RESOURCE_ID);
just after finished creation, I make a call on SetWindowTile by
p.SetWindowTitle(_T("Opps"))
Whenever the SetWindowTitle code being executed, an illegal operation
will be thrown. I can avoid this problem if I place the SetWindowTitle
in InitDialog of the property page. But that is not I want.
May I know why calling the SetWindowTitle just after the creation of
dialog/ property page will cause illegal operation. How I can solve
this?
Thanks.
|
|
|
|
|
Property pages do not exist until that are "activated" for the first time. The documentation for CPropertySheet::AddPage() states:
"AddPage adds the CPropertyPage object to the CPropertySheet object’s list of pages but does not actually create the window for the page. The framework postpones creation of the window for the page until the user selects that page."
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
p.m_psp.dwFlags|=PSP_USETITLE;
strcpy(p.m_psp.pszTitle,"Opps");
or even
p.m_psp.dwFlags|=PSP_USETITLE;
p.m_psp.pszTitle="Opps";
Could this solve the problem ? I think it crashes only because the window does not exists, and SetWindowTitle asserts the window handle somewhere.
~RaGE();
|
|
|
|
|
The property page has to be created first... the constructor just initializes the class, but not the window itself -> without window, no window title change!
Don't try it, just do it! 
|
|
|
|
|
Hi all,
I have this tiny dll which exports a single function (as extern "C")
looking like this:
<br />
void test123(int *t)<br />
{<br />
*t = _open("c:\\feedback.xml", _O_RDONLY | _O_TEXT);<br />
}<br />
Now the problem is: if I use this in a test program like this:
<br />
test123(&fd);<br />
FILE* fp = _fdopen(fd, "rt");<br />
I get a pretty weird crash in _fdopen(). I also tried to use the fopen call in the test123 function and let it return the FILE*. Now it won't crash but I can't read from it either. Any body got an idea what's going on?
(what I'm actually trying is to read from a buffer through a FILE*. I'm creating a pipe, write the contents of the file to it, pass on the filedescriptor of the read end and transform it to a FILE* with _fdopen. So if anybody can provide me with another way to do this, plz let me know. But it is very important that I can use a FILE* to read from the buffer. Has to do with a porting job...)
I used to have a life ... now I have a computer
|
|
|
|
|
Shouldn't you be checking the value of fd to make sure it is not -1? This would indicate that _open() failed.
To eliminate the DLL as part of the problem, put the calls to _open() and _fdopen() in the same spot. Does it work then?
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
If i put the calls in the same location, it works perfectly well. I did check the return value. It was 3, as one would expect.
I used to have a life ... now I have a computer
|
|
|
|
|
bisserke wrote:
I did check the return value. It was 3, as one would expect.
Why would you expect the return value of _open() to be 3? Since when do handles have known values?
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
because 0,1,2 are default so normally, in this little app, the first one free is 3.
I used to have a life ... now I have a computer
|
|
|
|
|
IIRC, file handles are local to the instance of the C-runtimes in which they are created. if your DLL and your calling program are not using the same instance of the C-runtimes, they cannot share file handles.
this applies to memory too: malloc/new across DLL boundaries = bad, if the DLL and EXE use different CRT instances.
so.. are your DLL and EXE statically linking to the CRT or, using dynamic linking ?
Cleek | Image Toolkits | Thumbnail maker
|
|
|
|
|
Well they are dynamically linked. So I'm gonna look into this. Looks like a good lead.
(I'm actually pretty new to Windows environments...)
thx
I used to have a life ... now I have a computer
|
|
|
|
|
bisserke wrote:
Has to do with a porting job.
If you're going for portability, then you should probably just put the functionality in a standard library (which has to be staticaly linked).
If you are putting the functionality into a DLL then the DLL should be handling all the file I/O. That is it should export the functions for reading/writing and any other file related activity required.
Good Luck!
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
I have an application that launches a wizard based property page that contains N property sheets. All of the pages are added to the property sheet at initialization.
At one point in the wizard, it has a group of radio buttons that determine which sheet should be shown next. I am able to get to the next page without a problem. However, when I press back, it should skip all the pages in between and go back to the radio button selection page. I am using the following code to go back:
LRESULT CPropPageOptions::OnWizardBack() <br />
{<br />
CPropSheet* pParent = (CPropSheet*)GetParent();<br />
ASSERT_KINDOF(CPropSheet, pParent); <br />
<br />
switch(pParent->m_nScheduleType)<br />
{<br />
case 1:<br />
return pParent->SetActivePage(&pParent->m_pageWeekly);<br />
case 2:<br />
return pParent->SetActivePage(&pParent->m_pageMonthly);<br />
case 3:<br />
return pParent->SetActivePage(&pParent->m_pageOneTime);<br />
default:<br />
return pParent->SetActivePage(&pParent->m_pageDaily);<br />
}<br />
return TRUE;<br />
<br />
}
This doesn't seem to work correctly. It goes back through all the pages one at a time. Is there any way to make this work correctly, short of redesigning this so the pages are added as they are needed?
Brigg Thorp
Senior Software Engineer
Timex Corporation
EDITED - the returns in the switch statement are now present.
|
|
|
|
|
You forgot to break. If that's exactly what you wrote, cut-and-pasted, it will always drop through the bottom of each case, meaning that m_pageDaily is the page shown.
Stability. What an interesting concept. -- Chris Maunder
|
|
|
|
|
Actually, I had returns in there...don't know why they didn't show up. This is how it actually is.
LRESULT CPropPageOptions::OnWizardBack()
{
CPropSheet* pParent = (CPropSheet*)GetParent();
ASSERT_KINDOF(CPropSheet, pParent);
switch(pParent->m_nScheduleType)
{
case 1:
return pParent->SetActivePage(&pParent->m_pageWeekly);
case 2:
return pParent->SetActivePage(&pParent->m_pageMonthly);
case 3:
return pParent->SetActivePage(&pParent->m_pageOneTime);
default:
return pParent->SetActivePage(&pParent->m_pageDaily);
}
return TRUE;
Brigg Thorp
Senior Software Engineer
Timex Corporation
|
|
|
|
|
Brigg Thorp wrote:
It goes back through all the pages one at a time
Are you aware of that :
Returned Value (of OnWizardBack):
0 to automatically advance to the next page; –1 to prevent the page from changing. To jump to a page other than the next one, return the identifier of the dialog to be displayed.
So be careful to what you actually return, because pParent->SetActivePage(); is always a BOOL.
~RaGE();
|
|
|
|
|
I figured out what the problem was. I needed to set the active page first, then return -1 to tell the base class to not change the page, since I already did. Code as follows:
LRESULT CPropPageOptions::OnWizardBack() <br />
{<br />
CPropSheet* pParent = (CPropSheet*)GetParent();<br />
ASSERT_KINDOF(CPropSheet, pParent); <br />
<br />
switch(pParent->m_nScheduleType)<br />
{<br />
case 1:<br />
pParent->SetActivePage(3);
break;<br />
case 2:<br />
pParent->SetActivePage(4);
break;<br />
case 3:<br />
pParent->SetActivePage(5);
break;<br />
default:<br />
pParent->SetActivePage(2);
}<br />
<br />
return -1;<br />
}
Regards,
Brigg Thorp
Senior Software Engineer
Timex Corporation
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
