|
thanks for your reply but VC++ doesn't support ASP.net and I have no idea about how i can connect the java with MFC.
|
|
|
|
|
Dude... use your head. The suggestion was to create an ASP.NET or Java front end to your database. Java or ASP.Net can be used to develop a web-based front end. It doesn't have anything to do with MFC - it's an alternative approach, and one much better suited to your design goal. MFC was not intended to be used as a web UI framework. Yes, you can probably port your logic to a CGI app, but it's an ugly, error-prone and time-consuming approach, compared to using a framework that is INTENDED to be used to develop web-based UIs.
L u n a t i c F r i n g e
|
|
|
|
|
You need to redo your UI (front-end) to be web oriented ( asp, flash, silverlight, ... ) that calls something server-side.
unfortunatly, I don't think you can do the front-end with MFC.
good luck.
Watched code never compiles.
|
|
|
|
|
Thanks for all
I'll try each suggestion and all replys appreciated.
|
|
|
|
|
What i try to acomplish: when the user presses VKMENU a textbox is shown. This works fine with one problem. When the editbox is shown it immidiatly also shows a contextmenu containing options for cut, paste, copy and so on.
This contextmenu is also shown when you rightclick in the editbox or press vkmenu while you are in the editbox. This is standard windows behaviour.
It seems that the key that triggers the code to show the editbox (vkmenu) is somehow routed to the editbox. My question: how to prevend this?
Note: When the user presses vkmenu while IN the editbox the contextmenu must still be presented.
Note2: When i change the code so that for example Alt-space will show the editbox the problem disappears, but that is not a solution in my case.
Note3: I've been experimenting with the returnvalue of the dispatcher, without any succes so far.
Any suggestions?
|
|
|
|
|
Show some code, how and where did you "catch" VKMENU and how did you handle it? Try adding a message handler for WM_KEYDOWN to your edit box and see if the VKMENU goes thorough there. If yes, you could either set some flag, if the flag is on, VKMENU is swalowed by your handler (does not pass it on to the __super version) and the flag is set off again, if it is off then it is passed along to the __super method. Then, when you "bring up" the edit, set the flag to on. Another aproach would be to clear the messsage queue of any incoming WM_KEYDOWN and/or WM_KEYUP messages targeted to your edit box after it has been created (you could do this using PeekMessage with PM_REMOVE specified). Don't know if any of these are doable or reliable though so if you choose to try them, be carefull...
[edit] I did some experimenting, it seems that the local menu is displayed when you release the "VKMENU key" so my guess is that you catch the keydown event, bring up the edit field, set the focus to it, and then when the key is released then the keyup events goes to your edit box and tadaa, it displays the menu. Maybe try displaying your box on keyup instead of keydown if that workds for you.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Sometimes you just have to hate coding to do it well. <
|
|
|
|
|
Code-o-mat wrote: [edit] I did some experimenting, it seems that the local menu is displayed when you release the "VKMENU key" so my guess is that you catch the keydown event, bring up the edit field, set the focus to it, and then when the key is released then the keyup events goes to your edit box and tadaa, it displays the menu. Maybe try displaying your box on keyup instead of keydown if that workds for you.
That is exactly what happens! Good answer. So either i swalow the VKMENU in the keyup-handler, or i set up the editbox at Keyup. Sounds simple. I'll be back is that's not the solution.
Thanks
|
|
|
|
|
|
Vaclav_Sal wrote: Could someone kindly explain this MS language to me in plain English?
“Return Value
The result of the message processing; its value depends on the message sent.”
What part do you not understand? If you sent WM_GETTEXT to a window, you will get the text that corresponds to that window returned to you. If you sent LB_GETCOUNT to a listbox control, you will get the number of items in the listbox control returned to you. If you sent WM_SETFONT to an edit control, you will get nothing back as that message does not return anything.
"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
|
|
|
|
|
Vaclav_Sal wrote: Could someone kindly explain this MS language to me in plain English?
“Return Value
The result of the message processing; its value depends on the message sent.”
Hi Vaclav,
The SendMessage Function[^] can be used for inter-process/thread communication. What the MSDN article is saying is that the LRESULT value returned from each window message is interpreted differently. For example:
WM_SETCURSOR Message[^] will return TRUE or FALSE.
WM_GETFONT Message[^] will return HANDLE or NULL.
And it is the same for all other messages... You cannot understand what the the LRESULT value means unless you also know what message was sent. (This is essentially what the sentence means)
Best Wishes,
-David Delaune
|
|
|
|
|
That is plain English.
You should realize messages are used for everything in Windows. It is reasonable that return values depend on the sent messages. 
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]
|
|
|
|
|
|
I think perhaps you misunderstand the architecture of Windows. The Windows system is largely based on messages being passed from one process to another. Whether the result comes from a function or not is largely irrelevant, it still depends on the value of the message. The fact that you think this is stupid is neither here nor there; that is the way the system has been defined by Microsoft, and that is how it works.
txtspeak is the realm of 9 year old children, not developers. Christian Graus
|
|
|
|
|
Richard MacCutchan wrote: The fact that you think this is stupid is neither here nor there; that is the way the system has been defined by Microsoft, and that is how it works.
And it works, indeed.
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]
|
|
|
|
|
Now why were you downvoted for that, I wonder - have a compensatory 5.
[edit]Ah, I see the OP has removed his posts; I guess that was his way of hitting back.[/edit]
txtspeak is the realm of 9 year old children, not developers. Christian Graus
|
|
|
|
|
Oh, thank you.
My post was actually quite useless (I just wanted to remark the message mechanism is IMHO simple, powerful, efficient).
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]
|
|
|
|
|
CPallini wrote: My post was actually quite useless
I always find your posts useful; even if they just make me  .
txtspeak is the realm of 9 year old children, not developers. Christian Graus
|
|
|
|
|
Thank you, Sir. 
The Clown of the forum 
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]
|
|
|
|
|
Oh, and I thought you were being sarcastic. 
You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists.
|
|
|
|
|
No, I really like such mechanism (on the other hand, there are certain framworks built on the top of it...).
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]
|
|
|
|
|
I guess with the Window's version, I always disliked the lack of type safety and the way it was laid out. I will concede that it is quite a legacy interface in this day and age. Not that anything Microsoft has come up with since then is a lot better. 
You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists.
|
|
|
|
|
It's C. The point is efficiency, I suppose.
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]
|
|
|
|
|
Yes, but even in C, I like my code pretty. I'd have declared a structure for each message type and just passed a pointer as part of the message. Or even the first field of the structure could have been the message type. Still not C++ type safe but I think more elegant. It would have made interpreting the message a bit easier than remembering which bit went it which parameter and still have pointers to structures occasionally flying by. But then I'm not a computer scientist. 
You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists.
|
|
|
|
|
Tim Craig wrote: I'd have declared a structure for each message type
Wow, tons of structs.
Tim Craig wrote: just passed a pointer as part of the message.
Pointers don't always make sense in Windows messages (pointers are process-scope valid).
Moreover, I think it is dangerous to use pointers in every Windows message, if you don't need a pointer, don't use it (don't get me wrong, pointers are useful, but, each time I see a pointer I ask to myself: is it valid? Should I free the memory?).
Tim Craig wrote: But then I'm not a computer scientist.
So I am: I'm just the forum clown... 
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]
|
|
|
|
|
CPallini wrote: is it valid?
Bill sent it to you. 
CPallini wrote: Should I free the memory?
Pick one and stick to it! But since when has Microsoft been able to stick to anything? 
CPallini wrote: I'm just the forum clown
And doing a damn fine job.... 
You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
