|
Well Richard,
Maybe I went away!
I'm still working with MFC 42, and DevStudio98. Works fine for me and my Customers. Have no reason to change Dev Platform.
Have built my own MFC Extensions to keep up with the times. Anyways, my market is not cutting edge, and a User Interface with as few changes as possible is most appreciated by my customers. I am proud to say that our user interface has changed very little over the past 30 years, other than in Screen Cosmetics. (We started our enterprise in Win 3.3), and of course there have been many extensions. Our Software ran very well on XP, refused to run on Vista, but, runs with very minor mods, on Win7.
Win8 is a bit of a challenge, Our Software was really never intended to run on a Mobile Phone! (A Sophisticated Cash Register!!), We hope for the best for Win10.
I found a certain amount of hostility on the site against those, like me, who refused to move with the times, and invest large sums in yet another development suite, which would solve problems I did not have in the first place.
Also, there is a learning curve to get familiar with each new edition of the suite, which has a 'Pay-Back' Time only, if it can do things quicker or better.
We never found that to be the case!
The New, as I call 'Synthetic' languages,(C# etc) I as owner, and by vast majority of Staff, will never go for!
At my age, I am not looking for other projects, or chasing new developments, I have a market in which my product sells.
It was just good to hear a familiar voice again, from one who gave us much helpful advice in the past.
Thanks Richard.
Bram van Kampen
|
|
|
|
|
Hi Bram,
I totally agree with what you say about using particular versions of development software, although you do sometimes get forced to upgrade as newer versions of Windows appear. As long as it keeps working, satisfies your customers, and makes a reasonable profit, then there is no real reason to change.
And thanks again for your kind words.
|
|
|
|
|
One solution would be to hook mouse and keyboard events: Hooks Overview (Windows)[^].
The advantage of this solution is that all events for the current desktop are detected regardless which window has the focus and which application is the active one. But it depends on your requirements if you want to reset the timer upon all activities or only upon activities for your application. In the latter case you can still use hooks by checking if your application is the active one and that mouse events are on the application window.
|
|
|
|
|
Well Thanks for your reply.
In my case I only want to monitor Mouse and Key Events in my own application, and want the screens to die, in particular if the App does not have the focus, and Mouse and Key events occur which are sent to another application.
What currently happens is that an employee is performing a Mundane -Idle Task- like pursuing old invoices. The employee is called away, for other more urgent tasks, but remains signed on to an application. Someone else can than a week later resume the Idle Task, under the still open account. I am trying to put a stop to that.
Your contribution has been most helpful,
Regards,
Bram.
Bram van Kampen
|
|
|
|
|
Then using CWinApp::PreTranslateMessage[^] to check for WM_MOUSEMOVE and WM_KEYDOWN might be the simplest solution:
BOOL CMyApp::PreTranslateMessage(MSG* pMsg)
{
if (pMsg->message == WM_KEYDOWN || pMsg->message == WM_MOUSEMOVE)
{
}
return CWinApp::PreTranslateMessage(pMsg);
}
It may be necessary to add a check for your application being the active one to avoid resetting the timer when the mouse is just moved over it.
|
|
|
|
|
|
Installing a system-wide hook to monitor mouse and keyboard activity would work but is also very "invasive." Another solution would be to call GetLastInputInfo() periodically.
"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
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
Hi, Thanks,
The invasive nature of installing a system wide hook for mouse and keyboard activity was really a concern, as appeared to be an overkill. so I have been thinking of using the App Message Map. I am really interested only in a 'Kick to Keep Alive' setup for my Cash Register Application. When the User is away, or, the Computer acting as Cash Register has switched context to another Application (Now THAT is an old fashioned term) the dormant Program should Quietly Log the current User Off!
Your idea is another one worthy of consideration, and further perusal.
Thanks,
Bram van Kampen
|
|
|
|
|
Now ,i have one question. I use library to define a matrix B, for example, as follows, how can i convert B.real() to a double[] array?
thanks very much.
MatrixXcd B(n,3);
for( int i=0; i<n; i++ )
for( int j=0; j<3; j++ )
B(i,j)=0;
|
|
|
|
|
I did not have used it so far but it should be possible to copy the values to your array this way:
double *da = new double[n * 3];
for (int i = 0; i < n; i++)
for (int j = 0; j < 3; j++)
da[i*3 + j] = B(i, j).real();
|
|
|
|
|
Thank you very much.
My code is in Loop many times, so i want a efficient code. your code can reach my function,but efficient i think it's not good.
|
|
|
|
|
It is difficult to answer without knowing how the data are used. But a short web reserach found this: [EIGEN] How to get in and out data from Eigen matrix | Vlad's Blog[^].
So it seems that you can use Map to get a pointer to the complex values. That should be sufficient because the real part is stored first and therefore already at the specified index (when *p is a pointer to a complex array, p[n] and p[n].real() have the same address).
|
|
|
|
|
Hi,
Working with MFC Ribbon designing Ribbon Menu with the help of XML .Now the problem is ,I want to design Menu by single-2 (.bmp)images not by the transparent Images Strip with the help of Index.
I have tried so many ways but don`t get any success.
<CATEGORY>
<ELEMENT_NAME>Category</ELEMENT_NAME>
<NAME>Home-Y</NAME>
<KEYS>H</KEYS>
<IMAGE_SMALL>
<ID>
<NAME>IDB_WRITESMALL</NAME>
<VALUE>110</VALUE>
</ID>
</IMAGE_SMALL>
<IMAGE_LARGE>
<ID>
<NAME>IDB_WRITELARGE</NAME>
<VALUE>111</VALUE>
</ID>
</IMAGE_LARGE>
<PANELS>
<PANEL>
<ELEMENT_NAME>Panel</ELEMENT_NAME>
<NAME>Clipboard</NAME>
<KEYS>D</KEYS>
<INDEX>1</INDEX>
<ELEMENTS>
<ELEMENT>
<ELEMENT_NAME>Button</ELEMENT_NAME>
<ID>
<NAME>ID_EDIT_PASTE</NAME>
<VALUE>57637</VALUE>
</ID>
<TEXT>Paste</TEXT>
<KEYS>V</KEYS>
<INDEX_SMALL>0</INDEX_SMALL>
<INDEX_LARGE>0</INDEX_LARGE>
</ELEMENT>
</ELEMENTS>
</PANEL>
</PANELS>
</CATEGORY>
The most important this, we can not change main tags of XML, beside you can change any thing related IMAGE TAGS,.
|
|
|
|
|
hi all,
i am taking help of this article for printing
Another ListView print (preview) sample.[^]
here i also want to save my print view of doctument to save as pdf.
how can i do this.
please help me for this.
|
|
|
|
|
You need to install a PDF printer driver to use as your destination device. Alternatively you can write the code yourself using a third-party library, or code it from scratch by studying the Adobe PDF specification.
|
|
|
|
|
can u please provide me any example of this.
|
|
|
|
|
Example of what? If you want to use a printer driver then Google will find you one. If you want to write it yourself then Google will again find you samples.
|
|
|
|
|
I am building my first class to output graphic to LCD connected to a micro.
Making small progress, however, since there is no proccess feedback form the LCD itself I have to "wait" until something, anything , shows on the LCD.
To test my code I opted to let the constructor paint the whole screen red.
Now for silly question.
I understand constructor function is to instantiate the class so the class methods can be used.
In general most constructors in micro world just take care of very basic - I/O pins assignments, serial baud rate etc.
Would it make more sense if I do all the painting OUTSIDE of constructor?
Or is is just one of those "personal preferences" ?
Eventually I will have more than one instance of this class running.
Thanks , any comments are as always appreciated.
|
|
|
|
|
When using the class multiple times it will make of course sense to perform the output in it's own function. Otherwise each usage will initially draw the same. Even for testing you can call that function (it is just one function call after creating the class).
While you can do anything you want in a constructor, it is often not utile. Because constructors did not return a value, you will often find an additional setup function that returns success/failure while the constructor only initialises members variables.
|
|
|
|
|
Vaclav_Sal wrote: To test my code I opted to let the constructor paint the whole screen red.
Painting sounds like a behavior rather than a setup. Thus the constructor isn't where it goes.
Vaclav_Sal wrote: in micro world
Far as I know micro coding tends to strongly favor execution efficiency. So that decides it. After that then for object oriented programming it follows the idiom that
1. The constructor does what must be done for the object to exist. If it fails then the object cannot exist.
2. Other than 1 everything else is behavior so a method not in the constructor.
So if you can't paint the screen red is that a error or does it mean that caller is done and cannot and must not proceed?
|
|
|
|
|
Thanks.
It definitely makes sense to utilize methods return values, something I do most of the time anyway, and let the constructor just do very basic.
As I mentioned, in the real case of LCD class, I do not have feedback from most of methods,so I need to change my debugging.
Instead of blindly painting the whole screen I'll just paint one pixel ( which I probably won't be able to see) and than read it back.
I guess I should walk before running, or better yet after falling down while running it is time to go back to walking.
|
|
|
|
|
|
If it clears things up at all....
If you ever write some C++ code using MFC (Microsoft's Foundation Class, essentially an OO wrapper around the WinAPI), you'll notice that there are always initialization routines aside from constructors (they're called OnInit...blah ).
If you happen to use a dialog object, and attempt to draw from the constructor instead of the initialization routine, you'll notice that the objects exist but are not windows yet so you'll get an assertion (if running in debug mode). This means that the constructors have been called but nothing has been drawn yet. The drawing only occurs after all the constructors have been called, the initialization routines are systematically called after that and you can load all the widgets with whatever the default values to be displayed are.
Moral of the story, drawing typically doesn't take place during construction of objects.
|
|
|
|
|
Hi,java has
-- modified 3-Apr-18 8:53am.
|
|
|
|
|
madhuresh sachan wrote: after this line cursor goes direct to the end of function,does not read below given code
What does this mean?
How did you know that the code is not read (executed would be a better word) if not using the debugger?
Your code snippet contains no operation that changes any GUI element (enables/disables items) so that you would not 'see' anything.
So run your program in the debugger and check what happens (e.g. by inspecting pRibbon, initial pos, lstItems.GetCount(), and the loop execution).
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
