C / C++ / MFC

Re: how to show a search bar in my class derived from CHtmlView

27-Apr-14 17:08

thank you for your help. i use VARIANT_TRUE and true, the problem keeps the same. and i copy the guid from msdn, it also keeps the same. anyone more suggestions?

Randor 27-Apr-14 17:34

Randor

27-Apr-14 17:34

Hi,

I see two errors:

Leon de Boer is correct that you should set vtShow.boolVal to VARIANT_TRUE;

I see another error... the third argument to ShowBrowserBar Function[^] should be a pointer to an empty VARIANT... not a NULL pointer.

C++

VARIANT vtEmpty = {0};

Best Wishes,
-David Delaune

Re: how to show a search bar in my class derived from CHtmlView

joshua013728-Apr-14 17:32

Re: how to show a search bar in my class derived from CHtmlView

28-Apr-14 17:32

thank your help info. i change the variable as code below, but the problem keeps the same:

C++

IWebBrowser2 *pBrowser = NULL;
// Ensure that our site is an browser window
HRESULT hr = m_pBrowserApp->QueryInterface(IID_IWebBrowser2, (void **) &pBrowser);
if (!SUCCEEDED(hr))
    return;

// Display the band object (the Search bar in this case)
VARIANT vtBandGUID, vtShow;
vtBandGUID.vt = VT_BSTR;
//把这里的CLSID换成你的工具条CLSID
vtBandGUID.bstrVal = SysAllocString(OLESTR("{30D02401-6A81-11D0-8274-00C04FD5AE38}"));
vtShow.vt = VT_BOOL;
vtShow.boolVal = VARIANT_TRUE;
VARIANT vtEmpty = {0};
hr = pBrowser->ShowBrowserBar(&vtBandGUID, &vtShow, &vtEmpty);
SysFreeString(vtBandGUID.bstrVal);
pBrowser->Release();

Randor 29-Apr-14 13:50

Randor

29-Apr-14 13:50

Hi,

Your code appears to be absolutely correct. The error you are encountering could be caused by the browser control not supporting explorer bars.

Best Wishes,
-David Delaune

Re: how to show a search bar in my class derived from CHtmlView

joshua013729-Apr-14 22:37

why my class derived from CHtmlView cannot show the 'Search' bar

29-Apr-14 22:37

thank you for you reply.
i think the reason is as you pointed out.
my enviroment:　windowsXP sp3 + IE8

joshua013727-Apr-14 2:29

what's the point of auto_ptr & unique_ptr?

27-Apr-14 2:29

C++

void CXxView::OnShowBar() 
{
	IWebBrowser2 *pBrowser = NULL;
	// Ensure that our site is an browser window
	HRESULT hr = m_pBrowserApp->QueryInterface(IID_IWebBrowser2, (void **) &pBrowser);
	if (SUCCEEDED(hr))
	{
		// Display the band object (the Search bar in this case)
		VARIANT vtBandGUID, vtShow;
		vtBandGUID.vt = VT_BSTR;
		//change the CLSID as your bar CLSID
		vtBandGUID.bstrVal = SysAllocString(OLESTR("{30D02401-6A81-11d0-8274-00C04FD5AE38}"));
		vtShow.vt = VT_BOOL;
		vtShow.boolVal = TRUE;
		HRESULT hrx = pBrowser->ShowBrowserBar(&vtBandGUID, &vtShow, 0);
		if (FAILED(hrx))
		{
			CString _str;
			_str.Format("0x%x", hrx);
			AfxMessageBox(_str);
		}

		SysFreeString(vtBandGUID.bstrVal);
		pBrowser->Release();
	}
}

Falconapollo23-Apr-14 22:41

Falconapollo

23-Apr-14 22:41

I just can't understand the meaning of unique_ptr or auto_ptr, as we all know, once the parameter gets out of its scope, we won't get memory leaks. However, is it a better idea if I create the parameter on the stack rather on the heap. I don't see its advantage over normal parameters. If we really need to create parameters on the heap, then we must use '

C++

new

' operator, right?

Here is a little code snippet:

C++

class Base
{
public:
	Base()
	{
		cout << "Base::()" << endl;
	}
	virtual ~Base()
	{
		cout << "~Base()" << endl;
	}
 
	virtual void iPhone()
	{
		cout << "I'm iPhone5s" << endl;
	}
};
 
class Derive : public Base
{
public:
 
	Derive()
	{
		cout << "Derive()" << endl;
	}
 
	virtual void iPhone()
	{
		cout << "I'm iPhone 6" << endl;
	}
 
	virtual ~Derive()
	{
		cout << "~Derive()" << endl;
	}
};
 
void main()
{
  {
 
      auto_ptr<Base> ptr(new Derive());//a foolish idea to do so?
      ptr->iPhone();
 
      Derive d;//isn't it better?
      Base* base = &d;
      base->iPhone();
 }
}

Maximilien24-Apr-14 3:32

Maximilien

24-Apr-14 3:32

Note: std::auto_ptr has been (mostly) replaced by std::unique_ptr.

The use of std::unique_ptr and std::shared_ptr offer better memory management (garbage control, ... ) than naked pointer (google for the difference between unique and shared).

C++

{
  Derive* p = new Derive;
  // will leak here
}

{ 
  std::unique_ptr<Derive> p(new Derive);
  // p will be deleted here, no leak.
}

In all (most) cases it would be better to not use pointers at all; but when it happens, use std::unique_ptr or stdshared_ptr depending on your need.

So in your example, it could simple be :

{ 
  Derive d;
  d.iPhone(); // no need to access the Base class.
}

In simple examples using one or the other will probably not make a difference, but in larger systems, it will.

I'd rather be phishing!

Albert Holguin24-Apr-14 5:24

Albert Holguin

24-Apr-14 5:24

It's essentially meant for the cases where you do need the heap... when you're already using new/delete. It eliminates the need to call delete explicitly and prevents leaks by taking care of the deallocation automatically. That's pretty much the crux of it (I personally don't use it at all).

jschell25-Apr-14 13:09

jschell

25-Apr-14 13:09

I never found it especially useful. By the time it arrived I had disciplined myself when I created code that I didn't see failures to deallocate anymore.

I did find that attempting to refactor code (others) that did have problems was at best a futile exorcize but maybe I never understood it in detail enough.

CPallini28-Apr-14 3:05

CPallini

28-Apr-14 3:05

Read about unique_ptr at "C++11 - the new ISO C++ standard" page[^].

Veni, vidi, vici.

Stephen Hewitt28-Apr-14 3:51

Stephen Hewitt

28-Apr-14 3:51

In general it may indeed be better to create it on the stack. The reason you'd use new is when you want more control over it's lifetime. For example you can't use the stack if it need to stay "alive" after the function returns (more generally, when it goes out of scope).

Steve

Win c Programming

Nawabpasha23-Apr-14 22:41

Nawabpasha

23-Apr-14 22:41

In Embedded programming working with Win c, can we develop Win c applications in visual studio, for that any special licence required.

econy28-Apr-14 8:50

econy

28-Apr-14 8:50

I develop Win CE program using VS2005,but need SDK from hardware vendor.
then my program can run on it's hardware platform.

Nawabpasha28-Apr-14 21:48

Nawabpasha

28-Apr-14 21:48

ok thank you for your reply, can u tell me if i am using visual studio 2008 or 2010 is there any necessity of SDK in these versions also, please help me.

econy29-Apr-14 4:57

econy

29-Apr-14 4:57

I think you need to ask the hardware vendor. for example, if you use ARM CPU, and Ｉ　assume you develop WinCE based program, then, either hardware vendor create a SDK for you, or you can create a SDK for yourself with PlatForm Builder.

PlatForm Builder is a software from Microsoft.

leon de boer30-Apr-14 4:02

leon de boer

30-Apr-14 4:02

Visual studio 12 will allow you to compile direct to Windows RT on an ARM processor which can be useful.

Personally however I cheat I usually write a UI interface that emulates the the embedded target on the PC or I have an old version of WINE which I have doctored and call Darkside which provides all the basic API interface of windows but runs a very simple concept of a device context and no multitasking.

It sort of weird I often have a linux thread kernel pushing into a faked version of Windows UI .... seems all wrong if you think about it.

The trick with all these techniques it to have a clear idea of interfaces on your embedded project so you can do the emulations. You can't just start random coding and hot and hope planning is everything.

SetWindowsHookEx

Mohsin Munawar22-Apr-14 23:36

Mohsin Munawar

22-Apr-14 23:36

Does it have any constraint in MFC, because the same code works fine when I run on win32 console. Will be grateful.

CPallini22-Apr-14 23:53

CPallini

22-Apr-14 23:53

SetWindowsHookEx [^] is a Windows API. Calling it (correctly) in a MFC application or in a Win32 console application is the same.

Veni, vidi, vici.

Malli_S23-Apr-14 2:01

Malli_S

23-Apr-14 2:01

What error code do you get?

[Delegates] [Virtual Desktop] [Tray Me !]

-Malli...!

Randor 23-Apr-14 10:26

Randor

23-Apr-14 10:26

Mohsin Munawar wrote:
Does it have any constraint in MFC

Yes.

The documentation for the SetWindowsHookEx function[^] states that calling the CallNextHookEx function[^] is optional.

This is not always the case for MFC windows. You need to always call the CallNextHookEx function[^] because the MFC classes may have hooks such as WH_CBT hook.

Best Wishes,
-David Delaune

Mohsin Munawar23-Apr-14 18:36

Mohsin Munawar

23-Apr-14 18:36

it works fine for some time on MFC. I get a feeling that it gets unhooked from the OS for some reason after approx 10 notifications