|
Hi every one
There is one application on my system that it’s opened my Clipboard and Empty it. but didn’t close Clipboard until closing the application .
I want attach to application by my application and send closeclipboard api to it.
Its my code but don’t work . how can i empty clipboard when it has been opened by another program?
Plz help me.
CWnd *pWnd=new CWnd();
BOOL bo,be,bc;
pWnd= GetOpenClipboardWindow();
pWnd=FindWindow("Application class name","Application title");
if(pWnd)
{
bo=pWnd->OpenClipboard();
be=EmptyClipboard();
bc=CloseClipboard();
}
modified on Saturday, July 11, 2009 8:01 AM
|
|
|
|
|
How to Get the installer path of Internet Explorer using C++
|
|
|
|
|
Why do you want to do that? The various reasons I can think of for needing the path to Internet Explorer could well be satisfied using a different method that doesn't need the path.
Aside from that, you could a) look at the Internet Explorer shortcut in the Start Menu (if there is one), or b) Look in the registry @ HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths.
But please answer the first question. There's usually a better way.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
thx stuart..but i need programatically plz help
|
|
|
|
|
Ummmm - you realise that you can do those things programmatically and that is precisely what I meant you to do....
But as I said - why do you need the path to Internet Explorer?
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
If it's the default browser, you could use FindExecutable() . There's also HKCR\http\shell\open\command in the registry.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"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
|
|
|
|
|
How to populate custom data in VSFlexGRID.
Any idea how to set custom data source to flex grid using C++/COM programing .
Any othe way efficient way for dynamic data population in VSFlexgrid.
|
|
|
|
|
You may possibly get help at their community[^]. This forum is for specific questions related to C/C++/MFC.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
I have a BYTE array that I'm trying to split into parts and put the parts in a vector:
#include <iostream>
#include <vector>
#include <algorithm>
#include <malloc.h>
#ifndef LPBYTE
typedef unsigned char * LPBYTE
#endif
void split(vector<LPBYTE>& vect, const LPBYTE& lpbData) {
LPBYTE start = lpbData;
LPBYTE end = lpbData + (size_t) 2;
size_t len = distance(start, end);
LPBYTE lpbPart = new BYTE[len];
memcpy(lpbPart, start, len);
vect.push_back( lpbPart );
}
int main() {
LPBYTE data = {'a', 'b', 'c', 12, 22, 'Q'};
vector<LPBYTE> parts;
split(parts, data);
for (vector<LPBYTE>::iterator vIT = parts.begin(); vIT != parts.end(); vIT++)
cout << (char *) *vIT << "\n";
parts.clear();
} The problem with the heap version is that it leaks.
But if I use the stack version, or if I were to delete lpbPart inside split() (after adding it to the vector), a bunch of garbage is output 'cause the address is no longer valid.
I could iterate through the vector when I'm done with it, delete -ing each element... but I was told recently that that is a bad programming practice.
I am leaning towards deriving a class from vector and delete -ing the elements in the destructor, but I thought I'd run it by you guys first and see if there was a better way.
OR if there is a way to make a sub-array of an array, where the sub-array points to an address within the array but has a length shorter than the distance from the address within the source array to its end. This way would avoid the stack and the heap and the addresses would be valid so long as the source LPBYTE data was valid. It isn't good code, but to better explain what I mean:
LPBYTE data = {'a', 'b', 'c', 12, 22, 'Q'};
BYTE sub[2];
&sub = data + 2;
As always, any help ya'll can give is greatly appreciated!
MZR
|
|
|
|
|
If you have used new[], you have to use delete[]. That is not bad programming practice. Rather, I would say that using new[] in the first place is bad programming practice.
Are you trying to create several smaller BYTE arrays from one large BYTE array?
If so, I would recommend creating a vector<vector<BYTE>> sub .
You could then assign values to sub as follows.
vector<BYTE> small;
small.assign(data.begin(), data.begin() + 2);
sub.push_back(small);
small.assign(data.begin() + 3, data.begin() + 5);
sub.push_back(small);
Or you can use Boost.MultiArray[^].
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
Mike the Red wrote: OR if there is a way to make a sub-array of an array, where the sub-array points to an address within the array but has a length shorter than the distance from the address within the source array to its end. This way would avoid the stack and the heap and the addresses would be valid so long as the source LPBYTE data was valid. It isn't good code, but to better explain what I mean:
Arrays==pointers. The size of an array is not (repeat NOT) stored with the pointer. So, you could store pointers into the original array in the vector, but you'd need to store some way of knowing what the end ot the part was. You could do it like this:
void split(vector<std::pair<LPBYTE, LPBYTE> >& vect, const LPBYTE& lpbData)
{
LPBYTE start = lpbData;
LPBYTE end = lpbData + (size_t) 2;
vect.push_back(std::make_pair(start, end));
}
and you'd have to declare parts as
vector<std::pair<LPBYTE, LPBYTE> > parts;
This concept is known as an iterator range and is supported within some[^] libraries[^].
The iterator range is what is known as a half-open range. What this means is that the start of the range is part of the range, but the end of the range actually points to the first element AFTER the range. Sounds odd? Well, it's the way that all the STL iterators and algorithms work, so these ranges have compatibility with those, which is a good thing, IMO.
HTH!
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
That's exactly what I was looking for - thank you!
I know you've mentioned BOOST to me a couple times, and I may look into it when I've learned a bit more, but if I use other people's code/libraries, how will I learn for myself?
MZR
|
|
|
|
|
Mike the Red wrote: I may look into it when I've learned a bit more, but if I use other people's code/libraries, how will I learn for myself?
Quite correct - but at the same time, you can't implement EVERYTHING yourself (you're using a compiler you haven't written yourself, I presume ). It's most important to learn concepts, how they work, and when to apply them. Implementation? Not always so important.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Hello
I am using DialogBox function to create a Modal dialog. But sometimes this dialog is behaving like a modeless dialog and let the USER click on other windows.
Is there a particular property i need to set to make sure that it behaves as a Modal itself?
Or is there any other function that i can use to create a modal dialog?
I am working on Win32 in Visual Studio 2003 environment.
Another issue is, i am using ShellExecute to open up a EXE from inside my Win32 app. Now when i have this exe open up and then open up my modal dailog, the modal dialog is always hidden behid the app i opened using ShellExecute.
Is there a way i can make sure that i can open up the modal dialog in front of the app i opened using ShellExecute?
Or do i have to close the app i opened using ShellExecute?
If i have to close that app, which function i have to use?
Do apps opened using ShellExecute run on a new process memory?
Thanks in advance.
|
|
|
|
|
A modal dialog is modal to its parent window, i.e., the parent window is disabled as long as the modal dialog is active. You will still be able to click on other windows on your desktop. What is the parent of the modal dialog?
And yes, all apps run in a new process memory irrespective of whether you opened it using ShellExecute or CreateProcess or by double clicking on the EXE from explorer.
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
I've been reading a couple of articles here about using custom draw to get XP and Vista themed buttons containing a bitmap, such as
Vista themed Owner-Drawn and Full-Custom Push/Menu/Image Buttons[^]
But I would prefer my buttons to look like toolbar buttons - i.e. by default look flat and without an outline, look slightly curved and with an outline when the cursor is hovered over it, and look pushed-in with a drop shadow when clicked.
Is there a simple way to get a CButton to look like this (not on a toolbar)?
|
|
|
|
|
BigInt BigInt::add_bigint(BigInt add)
{
int carry = 0;
int temp;
bool carry2;
stack<int> answer;
vector<int> tempvector;
vector<int> add_int = add.get_bigint();
while(bigint_int.size() > add_int.size())
add_int.insert(add_int.begin(), 1, 0);
while(bigint_int.size() < add_int.size())
bigint_int.insert(bigint_int.begin(), 1, 0);
cout<<add_int.size()<<" "<<bigint_int.size()<<"\n";
for(int i = size(); i > 0 ;i--)
{
temp = add_int[i] + bigint_int[i];
if(temp >= 10)
{
temp -= 10;
carry2 = true;
}
else
carry2 = false;
answer.push(temp + carry);
if(carry2)
carry = 1;
else
carry = 0;
}
if(carry)
answer.push(carry);
while(!answer.empty())
{
tempvector.push_back(answer.top());
answer.pop();
}
BigInt ret(tempvector);
return ret;
}
|
|
|
|
|
This might be the problem:
for(int i = size(); i > 0 ;i--)
should be
for(int i = size() -1; i > -1 ;i--)
I believe this is the problem, hopefully...
|
|
|
|
|
Problem: "Debug Assert Error" in VC++.NET
1) I have a Clistctrl object placed in a dialog.
2) An mfc worker thread calls a display function to update the Clistctrl.
3) The display function uses methods such as Clistctrl::setitemtext etc to update the Clistctrl display.
The application works fine.
--------------
However ONLY when I close the application
1) i get a "debug assert error".
2) I've noticed that the mfc worker thread crashes.
--------------
This "debug assert error" happens (I believe) because:
1) When the application closes, the Clistctrl object is destroyed.
2) But the display function that is called by the worker thread continues
accessing the destroyed Clistctrl object by calling the Clistctrl::setitemtext function.
3) Thus the thread crashes leading to the debug assert error.
-------------
Question:
1) Am i correct in assuming the cause of the "debug assert error" ? If not, correct me please.
2) How do i fix the above problem ?
Any help will be greatly appreciated
|
|
|
|
|
It sounds like you're right, though I don't know all of the intricacies of your code. But assuming you're right, I suggest that when you tell the program to exit (via CAppDlg), I'd call that separate thread and tell it to stop working. I would not in this case send a message to it, but instead call a function directly. Once that function exits, your app can continue to shut down safely.
Try that, and see what happens.
|
|
|
|
|
Hi,
How do i set an event handler for when the user clicks on the close 'x' button of the application window?
Also, please note that I'm a novice in VC++.NET.
Any help will be greatly appreciated.
|
|
|
|
|
do a search on WM_CLOSE in bing or goolge or another search engine. that should help.
|
|
|
|
|
Hi,
I've tried to exit the thread on the "close" event. Unfortunately, the worker
thread seems to crash somewhere in between the following 2 instants.
a) when the user clicks on the close button 'x' of the
application window AND
b) when the "close" event handler is called.
Thus the "Debug Assert failure "problem persists.
Should i try the suggestion posted by Stuart Dootson ?
Any help will be greatly appreciated.
|
|
|
|
|
A) Is the CDialog::OnClose() method called before or after you try to shut down the thread? This could have been a quick hack to fix the problem, though not a solid solution.
B) Seriously, Stuart is right. Threads should post messages to the main application, and not to dialogs directly, that way pointers and objects that are not valid are thrown away easily by the operating system, and you don't have to worry about this sort of thing consistently. I would rework the code as suggested by Stuart. But it shouldn't be that difficult.
|
|
|
|
|
You don't want to manipulate UI from a worker thread. You can post windows messages safely enough, but calling control methods will, at best, send a message rather than posting it, which isn't a good idea, believe me.
Try posting an app-specific message to the UI threads queue using PostThreadMessage. Respond to that message in the UI by redrawing the UI.
Also, you probably want to tell the worker to stop before terminating and wait for it to do so.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|