|
Hello,
I m using Microsoft Visual Studio 6.0 editor.
When I build my application and when I Execute (ctrl + F5) my application
then again a build dialog box is get displayed (which is displayed during Build (F7)
the application) & it ask me for build the application (having option Yes, No, Cancel).
I 'Clean' the application & then Rebuild it, then also
this problem continues. Also I delete the 'Debug' folder from the current directory
& then Rebuild application then also that problem is not solved.
Plz give me solution.
Thanks in advance.
Regards
Nikesh.
|
|
|
|
|
Is the date and time set correctly on your machine? Is it rebuilding the entire project, or just a subset of files? If the latter, are they the same files each time?
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
|
Date and time set correctly on my machine. It rebuilding just a subset of files. And same files ask for
build each time.
Regards
Nikesh
|
|
|
|
|
Are you making any changes to the code such that a rebuild is indeed justified?
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
|
I write VST plugins. These plugins use a lot of custom controls, e.g. knobs, sliders, etc. I've rolled my own library for these controls using Win32 and GDI+ mainly because it's hard to get VST to play nicely with MFC (long story).
What I do is use a resource editor and drag and drop the user control type onto the dialog surface. This makes it convenient to place controls in the correct position rather than trying to do it manually in code.
Anyway, I have a commercial plugin called Cobalt. It's been out since last January. Since then I've gotten a few rare bug reports that custom controls are not in the correct position. It's as if the scale the controls is using is larger than the underlying dialog they belong to.
Here is a screen shot of what I mean:
Messed up GUI[^]
Here is a screen shot of what it's suppose to look like:
Normal GUI[^]
The GUI comes in two sizes: Small and Large. I can flip between the two sizes in code with preprocessor directives so that it's easy to compile the resulting dll so that it uses one of the two sizes. My first thought when I came across this bug is that the code for the smaller size was using the coordinates for the larger size. But apparently both sizes suffer from the same bug on systems where this is a problem. And this doesn't explain why on the majority of systems the GUI looks correct. So I don't think it's related.
My biggest problem is that I can't reproduce the bug. So it's almost completely guess work. Could the units the code is using to place the controls be different somehow than what the system is using? I'm not even sure that question makes sense. I'm having a hard time figuring out what the issue is here (obviously). Thanks for any help.
EDIT: I think it's related to fonts somehow. The font type/size of the dialog box the controls belong to scales the overall position of the controls... I'm not to a point of having a coherent thought on this quite yet, lol, but I think I've found the trail.
EDIT2: (kinda going back and forth between two forums where I've posted this question):
My resource file specifies the font type. It seems as though on some systems the font type is bypassed... or something. If I delete the FONT line from the resource file, I can recreate the bug. Without the FONT specification in the resource file, Windows assumes (I think) a different type of font than what I used to create the resource file with, thus the positions of all of the controls are thrown off.
modified on Friday, November 14, 2008 2:18 AM
|
|
|
|
|
Could this be related to the DPI setting in windows? The user can set the DPI for the screen (so he gets bigger or smaller fonts, RightClick desktop, properties, dispay, advanced, Screen DPI). We had issues with this too since the dialog units the resource editor works with depend on the font setting, as you said in your post. Maythe the users who experienced that bug had a different than default DPI setting on their desktops.
|
|
|
|
|
Anthony S. wrote: Could this be related to the DPI setting in windows? The user can set the DPI for the screen (so he gets bigger or smaller fonts, RightClick desktop, properties, dispay, advanced, Screen DPI). We had issues with this too since the dialog units the resource editor works with depend on the font setting, as you said in your post. Maythe the users who experienced that bug had a different than default DPI setting on their desktops.
Yup. You're right. By changing the DPI on my system, I was able to recreate the bug.
What was your solution for this? Or is there one?
My stopgap approach is to use MoveWindow() to manually set the control positions on the dialog box. While this works, it's very tedious.
|
|
|
|
|
Well, i think your problem is that while your controls get positioned and sized according to the font setting, your background images don't. What i did was to stretch the background bitmap to make it bigger or smaller as needed (mostly based on the containing window size, since this gets bigger or smaller too). This can make the interface a bit blurry because of the stretching (also stretch-blitting is a slow process) but for one, it's still better than it getting scrembled and two, if the user doesn't want to (or cannot) use the default DPI setting, he should accept that this will make the interface look a bit less crisp. Something for something...
Btw we are not the only one who didn't originally think of this case, when you have a different DPI setting and you log out of windows it displays the "Saving your settings window", and the header of this window doesn't fill fully the area it was given...looks a bit lame... 
p.s: i changed my displayed name in the meantime (Anthony S. -> Code-o-mat), don't get confused, it's still me.
|
|
|
|
|
Please help!
My program is working alright in XP, but the editbox of it is non-working in Vista! Why???
|
|
|
|
|
LaHaHa wrote: Why???
Without providing any more information, it could be most anything. Does it happen with all edit controls, or just a specific one? Does it happen with a new project having default options, or just a specific one that you've been working on?
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
|
Many thanks
I had solved it, the parameter of brush is wrong.
But it works in XP and doesn't work in XP!
|
|
|
|
|
|
Hi,
After I've converted my MFC application from VS2005 to VS2008 in the debug runtime I've got error:
"Unable to start program C:\Proj\...\Conv1.exe
This application has failed to start because the application configuration is incorrect.
For more details, please see the application event log."
In event viewer I've found error:
Source:SideBySide
Event ID: 59
Description: Generate Activation Context failed for C:\Proj\...\Conv1.exe. Reference error message: The referenced assembly is not installed on your system.
When I looed into manifest I've found dependencies on MFC and CRT of both VC90/VC80 (VS2005/2008).
I have to somehow get rid of VC80 dependencies in the manifest.
- HOW CAN I DO THAT???
Thanks in advance.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>
</requestedPrivileges>
</security>
</trustInfo>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC90.DebugCRT" version="9.0.21022.8" processorArchitecture="amd64" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC90.DebugMFC" version="9.0.21022.8" processorArchitecture="amd64" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC80.DebugCRT" version="8.0.50727.762" processorArchitecture="amd64" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC80.DebugCRT" version="8.0.50608.0" processorArchitecture="amd64" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
</dependentAssembly>
</dependency>
</assembly>
|
|
|
|
|
This means you are using some library which was compiled with VC8.0.
-Saurabh
|
|
|
|
|
Thanks for the hint.
This means I have to recompile all MFC dependent libraries with VS2008, and thereafter convert the project?
|
|
|
|
|
Please consider the following simply C++ program:
<br />
#include <iostream><br />
#include <cassert><br />
<br />
using namespace std;<br />
<br />
class A {<br />
public:<br />
int operator ++(int z)<br />
{<br />
cout << "++ called with " << z << endl;<br />
return 5;<br />
}<br />
int operator *( int z )<br />
{<br />
cout << "* called with " << z << endl;<br />
return 5;<br />
}<br />
int x;<br />
};<br />
<br />
int<br />
main()<br />
{<br />
A a;<br />
a.x = 25;<br />
a ++;<br />
a * 35 ;<br />
}<br />
<br />
In this case, the class A is defining two operators: ++ and *. For the operator *, I specify only one argument because I expect the first operand to be represented by the this pointer. This works as I would expect. Now for the operator ++. Since this is a unary operator, I would expect the function declaration not to have any arguments. However, it works with one argument. By the way, the expression, a ++ 5 does not compile.
Could somebody please tell me what I am missing?
Bob
|
|
|
|
|
|
The overload can't break the rule that the operator ++ is a unary operator!
|
|
|
|
|
Hope this is a simple question with a simple answer...
I am creating a modeless CPropertySheet object using CPropertySheet::Create( ).
What I want is:
1. Modeless
2. pParentWnd to be desktop (?) - so its focus NOT tied to the app which launched it.
3. its look to resemble the default look of a CDialog::doModal() instance
What do I supply for the DWORD dwStyle (and possibly dwExStyle) parameters for ::Create( )?
p.s.
I am still having problems with the FOCUS. What I need is for my popup, modeless property sheet to remain in the forefront (on top) of the window that launched it.
Tried UNsuccessfully with calling the constructor with CWnd::GetDesktopWindow() as well as the create function.
Thank you.
John John
modified on Thursday, November 13, 2008 4:43 PM
|
|
|
|
|
Hi !
I would to know how to generate a key with the ECDSA algorithm from openssl
or do I have to use the ECDH algorithm for that?
If I have to use ECDH, how do I generate a key ? ECDH is only to share a
secret key.
An other question: I am doing cryptography with EDCSA an/or ECDH I would
like to use less code lines from openssl as possible. What should I keep or
leave from the code.
Thanks! Hope you will understand my question.
|
|
|
|
|
|
I don't understand what you mean.
Thanks
|
|
|
|
|
Hi,
I have created a multi line edit control and assigned a member variable say m_strOutput...
when i do m_strOutput += _T("\n") expecting the next time string to be printed in next line , the string is not printed in next line but appended to previous string.... How to go to next line in edit control????
|
|
|
|
|
sribachana wrote: when i do m_strOutput += _T("\n")...
Have you tried \r\n instead?
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
|
yes i tried that also but no result
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
