|
Thank you,
Please suggest any article....
|
|
|
|
|
Why do you need an article?
Suppose your image has the following original dimensions {w,h}.
If the minimum allowd rectangle has {wmin,hmin} and the maximum has {wmax, hmax} then:
double smin = (double)wmin/w < hmin/h ? wmin/w : hmin/h;
double smax = (double)wmax/w > hmax/h ? wmax/w : hmax/h;
are the minimum and maximum scale factors (ofcourse you have to check in advance for division by zero - that is left as an exercise -).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
First you determine the minimum and maximum zoom factors that you want, probably by comparing the actual image size with the available space.
Then you map minZoom and maxZoom to your minimum and maximum slider values, with minSlider=0 it would be as simple as:
zoom=minZoom + sliderValue*(maxZoom-minZoom)/maxSlider
if it is a linear relation you want.
check: fro sliderValue=0 it gives zoom=minZoom, and for sliderValue=maxSlider it gives zoom=maxZoom.
|
|
|
|
|
I have an application written on MS Visual C++ 6. In one of mu customers (WinXP Japanese) the application fails right after start. After studying crash dump i saw the following:
My app in its InitInstance intercepts several user32.dll functions: GetSysColor, GetSysColorBrush, DrawFrameControl. I needed this to implement my own skinning. The interception is performed by widely used 'code injection' method: I locate necessary function in loaded user32.dll and write into its begin byte 0xe9 (command 'jump near'), then 4 bytes - relative address of my intercept function. Before this operation I suspend all threads of my application.
This worked fine on lot of customer's PCs. But on one PC the application fails right after this intercept is done - after this myapp calls LoadString, and I get Access Violation. Call Stack is:
user32.dll!__LockResource@8()
user32.dll!_LoadStringOrError@20()
user32.dll!_LoadStringW@16()
mfc42u.dll!AfxLoadString()
mfc42u.dll!CString::LoadStringW()
<my code that calls CString::LoadStringW>
It turned out - this customer has installed a software named Humming Heads Security Platform (http://www.hummingheads.co.jp/). This is a security monitor that controls many aspects of every application's work. From the crash dump I see: several DLLs of this Humming Heads Security Platform are embedded into my process. My version is: it intercepts API functions too, and this lead to conflict with my interception (somehow). If I turn this interception off in my application, it does not fail. What can you say about:
what exactly happened?
what can I do?
will it help if I will do the API functions interception using other method known as 'Modification of import/export tables'?
|
|
|
|
|
I saw a near-identical issue over ten years ago with a product that I was working on at the time. We used a 3rd party library for something and it had implemented a message hook of some sort but was not passing the unhandled messages on to the next hook in line (ours).
"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
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
Hi,
I have an editor in my application which has a find functionality implemented for it.The user will enter text in the editor and will try the Find option from menu.The problem is when I have n double byte characters(of japanese) in my text and say if I try to find an char or word which after the double byte chars then my search is displaced by n bytes.This issue happens only in japanese and the same application works fine in English.Going through the below blog which has a similar problem as that of mine I noticed that the problem is with the dependancy on ComCtrl 6 dll used in xp manifest theme.
http://www.insidercoding.com/post/2008/08/06/Visual-C2b2b-60-2b-XP-Manifest-3d3d-Problems.aspx
My application is also developed in vc6 and we use a manifest file for XP visual theme as below
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="1.0.0.0"
processorArchitecture="X86"
name="wm"
type="win32"/>
<description>Merely an XP test.</description>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="requireAdministrator" uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="X86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
</assembly>
And I also cannot move my application to unicode. There are ASCII functions in my code.MFC by default supports MBCS.Even after placing _MBCS in project settings doesnt solve my problem. When I debug the below code I found the problem with lstrlen which is returning n chars extra for n double byte chars in my text to find.This happens only when I debug the code in japanese OS , the same works fine when I debug the same application in English OS.
static
int
FindStrPos( LPSTR lpSrc, LPSTR lpFind, BOOL bMatchCase )
{
LPSTR p;
int pos = -1, len;
char szFind[FIND_LEN];
LPSTR lpStr;
lstrcpy( szFind, lpFind);
if( !bMatchCase ) {
len = lstrlen(lpSrc)+1;
lpStr = (LPSTR)wwHeap_AllocPtr( hChunkWM,
(GMEM_MOVEABLE | GMEM_ZEROINIT), len );
if( lpStr ) {
_fmemcpy( lpStr, lpSrc, len );
_fstrupr( lpStr );
_fstrupr( (LPSTR)szFind );
p = _fstrstr( lpStr, (LPSTR)szFind );
if( p ) {
pos = p - lpStr;
}
wwHeap_FreePtr( hChunkWM, lpStr );
return( pos );
} else {
debug("Alloc failed compare case-sensitive");
}
}
p = _fstrstr( lpSrc, lpFind );
if( p )
pos = p - lpSrc;
return( pos );
}
I also used MBCS functions like _mbslen instead of lstrlen and _mbsstr instead of _fstrstr then _mbslen is returning accurate length in japanese and when while finding the difference between the search position and actual text pos the value of pos is again added with n bytes in japanese version for n double byte chars in Text.
I tried removing the manifest file as the unknown problem is with the dependancy of comcontrl dll version 6 for enabling Xp style but it is giving other problems in japanese.
Any suggestion would be helpful.
Thanks,
Satya
Today is a gift, that's why it is called the present.
|
|
|
|
|
I dont understand your problem point yet. Will you explain the point for short again?
|
|
|
|
|
Sure ..
say with a text having 6 double byte chars as below and if I try to find word My then my search is displaced by 6 chars
and the pos is returned at "th"
" DIM a;DIM b;{ ‚ ‚¢‚¤‚¦‚¨‚ ‚¢‚¤‚¦‚¨‚ ‚¢‚¤‚¦‚¨ } My Month "
using ascii version functions in my code
len = lstrlen(lpSrc)+1;
_fstrstr( lpStr, (LPSTR)szFind );
if( p ) {
pos = p - lpStr;
}
Using MBCS functions
len = _mbslen((unsigned char *)lpSrc)+1;
ucP = _mbsstr((unsigned char *)lpStr, (unsigned char *)(LPSTR)szFind );
if(ucP)
{
pos = ucP - (unsigned char *)lpStr;
}
This problem happens only in japanese OS and that too in my application's editor.
Removing the XP manifest file from my application folder seems to work fine.
Doing a sample application of the same and testing in both english and japanese OS is working fine.
Now I am changing my code to MBCS and then counting the double byte chars in my code and adjusting the position accordingly using below code.
int cPos = 0,count =0;
while(cPos<pos)
{
if( IsDBCSLeadByte(lpStr[cPos] ))
{
cPos = cPos + 2;
count++;
}
else
cPos++;
}
pos = pos - count;
Thanks
Satya
Today is a gift, that's why it is called the present.
|
|
|
|
|
Hi All ,
I am having a Project.lib and i need to convert it into Project.dll
When i Build Project.dll i am getting linker errors:
Sample.lib(Program.obj) : error LNK2001: unresolved external symbol "public: __thiscall Method::Method(void)" (??0Method@@QAE@XZ)
Sample.lib(Program.obj) : error LNK2001: unresolved external symbol "public: __thiscall Method::~Method(void)" (??0Method@@QAE@XZ))
Debug/Project.dll : fatal error LNK1120: 2 unresolved externals
Error executing link.exe.
I have added the Sample.lib to added Project Settings to be Linker and this class Method is used as Base class to one of the classes in Program.obj
The definition and declaration for class Main is in another Project all together which is an exe.
How can i solve this error?
Thanks for your time,
Hari
|
|
|
|
|
You got no MSDN installed?
...byte till it megahertz...
|
|
|
|
|
|
How would MSDN fix a linker issue?
It's time for a new signature.
|
|
|
|
|
Pfff. Doesn't it tell why this error is issued and isn't that good enough to fix it? Even simply googling would have lead to online MSDN, if he didn't have it installed, along with scores of other sites that tell the same thing.
...byte till it megahertz...
|
|
|
|
|
bleedingfingers wrote: Doesn't it tell why this error is issued and isn't that good enough to fix it?
Possibly, but rather than ask if he has it installed you could have posted a link to the page with the solution so the OP understands what you meam.
It's time for a new signature.
|
|
|
|
|
Yeah, must have. I figured he could get what I meant but he didn't seem to 
...byte till it megahertz...
|
|
|
|
|
This typically looks like you forgot to provide a body for the constructor and destructor of your Method class.
|
|
|
|
|
You have a call to a Method() constructor and destructor in your module Program, but you have not included the body of the class in your project. Alternativel you need a extern "C" declaration around your class.
It's time for a new signature.
|
|
|
|
|
I try this way ,but feel it doesn't safety.
#include "TestDlg.h"
class CMainDlg : CDialog
{
public:
CTestDlg *m_pTestDlg;
void ShowDlg();
void FreeDlg();
}
void CMainDlg::ShowDlg()
{
m_pTestDlg = new CTestDlg();
m_pTestDlg->Create(IDD_TEST_DLG,this);
m_pTestDlg->CenterWindow();
m_pTestDlg->ShowWindow(SW_SHOWNORMAL);
m_pTestDlg->UpdateWindow();
}
void CMainDlg::FreeDlg()
{
if( m_pTestDlg != NULL )
{
delete m_pTestDlg;
}
}
Is this right ?
How to safty free the memory ?
Thanks for your reply !
Best Regards !
|
|
|
|
|
You could try the following :
void CMainDlg::FreeDlg()
{
if (m_pTestDlg) {
if (m_pTestDlg->GetSafeHwnd()) {
m_pTestDialog->EndDialog(IDCANCEL);
}
delete m_pTestDlg;
m_pTestDlg = NULL;
}
}
void CMainDlg::OnDestroy()
{
FreeDlg();
}
virtual void BeHappy() = 0;
|
|
|
|
|
Another point is that there is no point in having a pointer for your dialog if you at any point are worried about memory. You could just use CTestDlg m_testDlg;
Using a pointer as you have has only one advantage. You can use a forward declaration of CTestDlg in your header file to avoid compile time dependencies. This will reduce compilation time if you later make changes to CTestDlg. In practice, this applies to large project only.
Also, the UpdateWindow() call is superfluous.
|
|
|
|
|
Normally I'd agree about using a member rather than a dynamically created object. However in the case of a modeless dialogue box you can have the problem of resetting the members of the dialogue (if the dialogue box is closed and reopened) which can lead to some funky fiddling with manually calling destructors and placement new. As soon as you start thinking about that you might as well just say sod it and recreate the object as you need to use it.
Cheers,
Ash
Edited as I said completely the wrong thing and confused Niklas. Sorry!
modified on Thursday, August 19, 2010 7:26 AM
|
|
|
|
|
When having a modal dialog I have never found the use of dynamically allocate the object. I just create it as automatic on the stack in whatever function I need it.
|
|
|
|
|
If I had a brain I'd be dangerous. I should really proof read what I write more. There was a finger faux-pas in my response, I should have said "modeless."
For a modal dialogue I wholeheartedly agree - you'd be cracked to not stick it on the stack.
Cheers,
Ash
|
|
|
|
|
A quick point...
IF you're creating a modeless dialogue box (created with Create) then make sure you kill it off using DestroyWindow, not EndDialog.
IF you do and you're sure that CTestDlg is only going to be created dynamically then overide PostNCDestroy to clean up the C++ object. It's a bit disgusting but there are so many MFC classes that do it you might as well join in the fun! The advantage is that all you have to do is destroy the window and it'll clean up after itself:
void CTestDialog::PostNCDestroy()
{
delete this;
}
Cheers,
Ash
|
|
|
|
|
The statement "delete this" is amusing. I always add the comment "// hari kari".
Anyway, common practice is to keep a pointer to the modeless dialog in the object that creates it so you can just bring it forward if it is reinvoked ie., the pointer is not null. What I do in this case is I pass the address of that pointer to the dialog object so it can null it when it is closed - usually preceding the "delete this" statement. The PostNCDestroy method then looks like this :
void CTestDialog::PostNCDestroy()
{
if( m_pSelf )
*m_pSelf = NULL;
delete this;
}
That is the best and easiest way I have come up with to deal with the issue so far.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
