|
In addition to sending the exact keys directly as Richard described (I think that method is basically replicating what a keyboard would do if I'm not mistaken), there is another way of achieving this. Sending messages to the application's control directly. Windows allows this and it's relatively easy to get the controls' ID's to send messages to them.
Use Spy++[^] to get control IDs and you can also intercept some messages to figure out how yours should be formatted.
Once you have control IDs, you can send messages using the SendMessage()[^] method.
Biggest problem with this method is that it's more of a hack than anything else. The control IDs are not guaranteed to be the same from one version of the software to the next.
|
|
|
|
|
Dear Friends,
Am developing a client server application. Am using MFC MDI. It has multiple class. One class is showing live values so i used Editbox and CListCtrl control. I was create these control in
onCreate() function. It shows live in
onDraw() function
GetDlgItem(IDC_EDITBOX)->SetWindowText(sLiveValues); it is also updating a value but it is getting flicker. If i use
InvalidateRect() function it is not flickering but not update any value. So i need to update live value in any control like EditBox,CListCtrl without flicker. How to avoid flickering. Please help me.
|
|
|
|
|
If I understand you correctly, you are calling SetWindowText() from onDraw(). This is a problem, because SetWindowText() invokes drawing of the control. So your apllication is permanently redrawing its GUI.
I would suggest that you store the values in the receiving function in a thread-safe way (look for CRITICAL_SECTION in the documentation). Then create a timer (look for SetTimer()) and in the timer function again in a thread-safe way copy the data to a local variable and display the copy with SetWindowText(). The OnTimer function could look something like this:
void YourDialog::OnTimer(UINT nIDEvent)
{
if (nIDEvent == YourTimerId)
{
EnterCriticalSection(&yourCriticalSection);
CString values = sLiveValues;
LeaveCriticalSection(&yourCriticalSection);
GetDlgItem(IDC_EDITBOX)->SetWindowText(values);
}
}
You can run the timer in any interval convenient for your users.
The good thing about pessimism is, that you are always either right or pleasently surprised.
|
|
|
|
|
Hi,
I have a Dialog based Application. The Dialog may be Maximised. The Dialog is divided in three panes. There is a Dlg Wide reporting Section at the bottom, The Top is vertically divided in two, the LH Pane shows a Tree Control, The LH Pane shows further details of the selected node.
The divisions between the panes must be 'User Draggable'. What MFC control is available (if any) to capture the mouse, and perform the dragging action.
Regards,.
Bram
Bram van Kampen
|
|
|
|
|
|
|
I'm trying to create a set that stores vertices where vertices are defined by this class:
Quote: class Vertex
{
public:
Vertex();
~Vertex();
Vertex(double x_set, double y_set, double z_set, int bezierInd);
double x,y,z;
int bezierIndex;
bool operator<(const Vertex& rhs);
bool operator==(const Vertex& rhs);
bool operator!=(const Vertex& rhs);
};
I don't really know if i need a an allocator, but compile errors tell me I do. Also do I need a custom comparator? I created this one :
Quote: struct vertexCmp {
bool operator()(const Vertex& a, const Vertex& b) const {
return a.bezierIndex < b.bezierIndex;
}
};
and I'm creating a set like this :
set<Vertex, vertexCmp> bezierPoints;
|
|
|
|
|
You don't need a custom allocator for that type (or frankly, any type - effectively).
Custom allocators are a way to speed things up, or to keep data localized (definitely not mutually exclusive goals).
You DO however definitely need custom comparator functions, and you are close to getting it right. Very close. Have you considered making the member comparators const themselves, e.g. "bool operator<(const Vertex& rhs) const;"?. 
++luck;
|
|
|
|
|
I do not understand why is the pointer address changing everytime during the output for a code while I am executing the same code?
The code:
int main()
{
int a;
a=100;
int *b;
b= &a;
printf("The address of a is %p\n", b);
return 0;
}
The gcc compiler output:
nikhil@nikhil-Lenovo-Product:~/Desktop$ ./a.out
The address of a is 0x7fff990d2f24
nikhil@nikhil-Lenovo-Product:~/Desktop$ ./a.out
The address of a is 0x7fffcec94eb4
nikhil@nikhil-Lenovo-Product:~/Desktop$ ./a.out
The address of a is 0x7fff70b595e4
nikhil@nikhil-Lenovo-Product:~/Desktop$
|
|
|
|
|
This is not raleted to C but on how executable programs are loaded into memory. Each time you start the program it is loaded into previously free memory space. The free memory space and possible start adresses are changing because there are also other tasks and programs allocating and freeing memory.
|
|
|
|
|
In addition to what already told you have to consider that the variable whose address you are watching is a local automatic variable that resides on the stack that is is even more variable.
|
|
|
|
|
That is not quite correct, since each process uses its own address space, and memory addresses within a program do not correspond to physical memory addresses. The system memory manager instead creates a virtual memory address space for each process and maps that space onto the actual physical addresses. These addresses may change, specifically when some of that virtual memory exceeds the physical memory available.
Therefore, theoretically, the system memory manager could guarantee to always provide the same memory pointer upon repeated runs of a program. However, the memory manager is written to be efficient, not consistent between runs. I'm not that much into the inner workings of system memory managers, but I suspect that - depending on the current address space mappings - they will try to place allocations in regions of continuous physical memory to minimize the time they need searching. These regions will vary for the reasons you mentioned: other services and programs that are also using (and releasing) memory.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Hi Stefan,
Mike Nordell below gave a probable correct answer in that it is most likely due to ASLR. We don't know for sure since the original poster did not include OS version. Many modern operating systems are implementing this now including Linux.
My suggestion for the original poster is to recompile his project with /DYNAMICBASE[^] disabled. If he gets the same result after recompiling with /DYNAMICBASE disabled then he should check if Force ASLR[^] is enabled. (I am assuming he is on Windows and compiling with gcc within Cygwin based on his shell prompt)
Best Wishes,
-David Delaune
|
|
|
|
|
Maybe ASLR is the answer. But I see a lot of open questions. For one, my understanding of ASLR is that it will only randomize the memory address of the code area, and that area is separate from both the stack and the heap areas. Second, even if ASLR does also randomize the physical address of the stack or heap areas, will that have an effect on data addresses within an application? AFAIK it should not! If that were true, how could memory virtualization work? Third, I've seen data addresses both stay the same and change to different values on restarting an application (the same application, without changes to the code), implying that the address modifications are not deliberate.
But as I said, I do not know the internals of the Windows memory manager. Maybe ASLR does have a subtle (possibly unintended) side effect that influences data memory addresses within the application.
Anyway, I see very little use in querying data addresses. They do not directly correspond to physical addresses, they can and will be affected by changes in the code, and they will likely be different on different machines, even if they can be made to stay conatant on the same machine. The only thing I use data addresses for is setting data breakpoints - and I try to avoid those normally since they tend to eat a lot of performance.
P.S.: I've just checked the Wiki Article on ASLR[^] which was a bit more informative than the ones you linked to: apparently, in Windows, the ASLR implementation does randomize stack and heap addresses too. The physical addresses, mind you. That doesn't explain variations of the virtual addresses visible within the application though.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
modified 13-Feb-15 3:21am.
|
|
|
|
|
Most likely ASLR - Address Space Layout Randomization.
The operating system is trying to help you not get pwnd due to easily exploitable crappy code.
|
|
|
|
|
Hi,
You are hitting at a genuine question here. Seeing that you use the GNU Compiler, I take it that you are running Linux. I take it, that you close down each exe, before starting the next instance. Then again, each instance starts in it's own virtual memory space. All your variables are stack based, and it suggests that Linux sets up a Random Stack Base, when a Process is started. This may be caused by the Debugger you use, if the results you display, are a result of Debugging Runs. Try it again in Retail Mode.
Whereas your question is of academic interest, I cannot see any practical implications, or even, Application. Anything that assumes a Fixed Location in Memory of Anything, relating to a running program, is ultimately bad design, and doomed to failure.
Kind Regards
Bram van Kampen
|
|
|
|
|
how do a write a code to switch on the LED using pic16f877A
|
|
|
|
|
|
By configuring the port with your LED as output (writing to the TRIS_x register) and setting the output state to the level which lets current flow through your LED (writing to the PORT_x register; the level depends on how the LED is connected).
|
|
|
|
|
What is that pic16f877A that you're going to use to write the code to turn the LED on?
I believe you're asking a question for some circuit board, if that is the case, then you should know that most of the board manufacturers have an API, and a developer forum that can guide you. You can use thode documents to get help in performing different actions, like the basic on turning the LED on.
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
Hello friends,
I have a HANDLE obtained by CreateFile() function call in windows, Is there any way i can assign that HANDLE to
CComPtr<istream>
|
|
|
|
|
|
Hello,
i'm a newbie in MFC programming and I'm writing a simple and silly program that change the background color of the window by selecting the color in the Menù.
I've created a menù with 5 color and each color has its own ID message.
I put the handler of these messages in the Document class of the program: i don't know if this is correct.
How can I change the color of background? I'm a bit confused because I would like to invalidate the client area and set the new color in OnDraw Method but I can't invalidate the area because if i put Invalidate() in the handler of the menù i get error.
These questions could be silly and obvious for an expert user but I don't know how to proceed. Can anyone suggest me the way to do? Best regards.
|
|
|
|
|
What type of view are you using? What error do you get when you call Invalidate()?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
If i put
Invalidate();
in the handler I get the message:
"error C3861: 'Invalidate': identifier not found
I have a doubt: Invalidate is a method of Cview class and I call this function inside a method of CDocument class. Is this calling correct? How can I call a method of a class inside a method of another class?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
