|
CliffRat wrote: The problem is that some locales/languages cannot be set with this method per MS (
You could implement your own solution of course.
Or just refuse to support those, perhaps by examining the requirement that stated they were needed in the first place. Specifically what is the realistic, not imagined, market share possible from those locations in the next year? Or the next five?
|
|
|
|
|
Just to let everyone know...
I posted this also to MSDN forums and they were able to duplicate the problem as it exists in VC++ 2005. They also pointed out that this issue had been corrected in VC++ 2010.
Of course, my problem is I need to keep working in 2005 for now...
C'est la vie!
|
|
|
|
|
I've written a C++ FTP Client to fetch files of a certain name pattern. I use FtpFindFirstFile which iteratively returns file data into the WIN32_FIND_DATA structure and it works great from dos (far end) to dos (near end).
However, when the far end is Unix, the string returned in the cFileName member of the WIN32_FIND_DATA struct also contains all the file attributes (file size, access rights etc.).
I'm sure it must be something simple, but how can I get it to work so I just get the actual filename returned ? It's a real pain as I need to use wildcards in my pattern match.
|
|
|
|
|
As far as i know there is no standard to what form the FTP protocol gives you a directory listing, it's basicly meant for a human to read, so different implementations might return the information differently making it hard if not impossible to make a universal parser. I guess Microsoft uses its own way to do it which can be parsed by the WinInet methods but unix goes its own ways. It might as well just be a simple line termination difference, e.g. windows expects a new-line at the end of lines while unix works with carriage-returns, or something like that. Don't know how to get around that.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
I've managed to configure my FTP client with the far end OS and parsed the results accordingly. Seems like a bit of a hack, but works.
|
|
|
|
|
Hi,
As code-o-mat stated, the old ftp protocol RFC describing the LIST/NLST commands neglected to standardize the output. However it might save you some time if you have a look at ftpparse[^] written by Dr. Bernstein[^]. It doesn't look very pretty but millions of servers across the world are using his internet software.
Best Wishes,
-David Delaune
|
|
|
|
|
Default message map is getting overloaded and application is getting freeze. I want to solve it by providing multiple message maps. Is that possible? If yes any example?
|
|
|
|
|
What do you mean by overloaded? There isn't a restriction in size that I'm aware of. 
Chris Meech
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
|
|
|
|
|
Well, each "derived class" of a CDialog has its own Message Map. That map is first in a "daisy chain" back through the base class (for as deep as the derivation chain goes). So, technically, you can have multiple maps.
I too am curious on how yours got "overloaded". Sounds like the daisy chaining is not set up correctly.
|
|
|
|
|
rahul.kulshreshtha wrote: Default message map is getting overloaded and application is getting freeze
You dont need a nother message map, you need to structure your code correctly: Dont wait in the message handling code, or do heavy work. Think of the message handler as a dispatcher.
Have it fire off threads to do the work, or to wait for events, ie, do the usefull stuff.
Then your app will stop freezing.
==============================
Nothing to say.
|
|
|
|
|
Good point. I was thinking "Overloaded" in the OOP sense and not in the "too much work to do in the time alloted" / "too busy" sense.
Is it time to argue about MessagePeek loops again? 
|
|
|
|
|
Chuck O'Toole wrote: Is it time to argue about MessagePeek loops again?
Well, as I said to the guy a few weeks back, the correct design is to put the work and waits into threads to leave the message processing unaffected. Anything else is a hack.
==============================
Nothing to say.
|
|
|
|
|
Thanks all,
Here is my answers:
It a share-market application which receives heavy broadcast from the server. I have a worker thread for receiving the data. After receiving the data, this thread formats data into structures and sends to another worker thread for processing. After processing that; thread posts a message (using ::PostMessage) to the active view to display the data. That view is only handling the display of the data but as the data is more it takes some time (200 milliseconds) to display. View is setting that data into a grid (UltimateGrid). Broadcast packet comes in every 500 milliseconds. Each packet contains data to be filled in approx 80 rows of the grids ( 80 * 9 cells). There is also color formatting and bold fonts on some cells. This all eats up 15 to 20% of the CPU. It freezes when I moves a child window over the grid while it was actually drawing the data on it. Just Because view was busy with handling the POSTMessages sent by broadcast thread. If I move the code which sets the grid cells, into any other worker thread then CPU utilization goes below 5% and view does not freeze but grid crashes when I scroll the grid, because internally it tries to copy the data from one row to another row however there is only one thread which updates the grid. Even though I also tried for synchronization in grid methods but that did not worked so now I am hanging between whether I should do cell setting on view (everything works fine but view freezes) or inside some worker thread (grid crashes but nothing freezes).
Is there any further optimization?
|
|
|
|
|
I've ran into a situation where ::PostMessage was over-flowing the message queue buffer. Make sure that your worker thread that does the ::PostMessage is ensuring that the message is successfully posted.
Chris Meech
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
|
|
|
|
|
yes I verified that. I wonder how other UI applications work fine when they have to draw a lot of things. For example a video player where it plays hundreds of frames in each second.
|
|
|
|
|
Most application avoid using the message queueing system but rely on some other mechanism to tell them when to render data. Once you are in a steady state running a video or receiving data and displaying it, you really don't need to messaging system except for keeping the display pretty (like repaint when uncovered) or handling user inputs like a cancel button or the scroll bar.
|
|
|
|
|
Hmm, if you really need data every .5 seconds, so much data that it takes .2 seconds to render it, then can you either cute down the frequency of data arriving at the screen? After all, it is for human eye ball consumption, does it really need .5 second updates?
Or, can you move the entire data display object into a seperate thread from the main window? I dont know, never tried it, but it might work.
==============================
Nothing to say.
|
|
|
|
|
yeah, that's what I was thinking until I read that the user can scroll through the data. Depending on what "scrolling through the data" means, he may have to retain all the data, even if it flashed by too fast for the user to see, they may want to go back and look at it using "scroll".
|
|
|
|
|
I was thinking about answering with some ideas but then I stopped. I need to know something more basic first.
If the output in the grid control is 80 rows and the user can scroll (you said that caused issues before) then my question has to do with the presentation of the data.
Where does "new data" show up in the grid? At the bottom? At the top?
How big is that control? 80 rows should take up quite a bit of vertical real estate.
What is the user scrolling through? By that I mean, when they scroll, are they looking to see older data? What happens to the newer data when the scroll causes it to be out of view?
I think that your idea to move the updates to the processing thread (or other) but not the GUI (using PostMessage()) is the right idea. It clearly has less overhead than clanking through the windows messaging system. Use the windows messages for things like redraw (Paint) or click events and not presenting new data. But the conflict with the user scrolling got me worrying about what the user is scrolling through. What is the users expectation of what they will see when scrolling through an application that continuiously presents new data? I think that's the area where you have to think about what it means and how you want to handle the responsiveness to scrolling.
|
|
|
|
|
Actually each row has a "trading-share or stock-share" in it so when data comes from servers I have to update the rows containing the old data. As there are thousands of share available in market, user can have hundreds of share in market watch grid to keep an eye with their prices and other details. As there may be 80 or more rows but the visible are can show only 60 rows so to see remaining he has to scroll down. It's not like chatting application where first row is the oldest row and bottom row is the newest row. Each row has a "stock name" and when it's update comes I have to update it.Currently I am planning to reduce the refresh rate and doing a batch update of multiple rows.
|
|
|
|
|
Well, if that's the case then the interlock between the scroll and the update should be relatively easy to manage. The thread that is doing the updates (assuming you move the update code out of the message loop) grabs a "lock" (an EVENT) before updating the cells and releases it when it's finished. The "scroll" message processing grabs the same "lock" before processing the scroll and releases it after. Neither should collide.
I assume you have worked out the issues with having a stock symbols location moving between any two bursts of input data due to scrolling as you do have scrolling working at all.
So, as I said in a previous post, it would seem to be better to process and update the control in one process away from the GUI message loop, something you've tried before and saw a performance improvement (reduced cpu usage) and probably enhanced responsiveness to the updates.
|
|
|
|
|
If the visible part of the control only represents some of the data, then can you maintain a sort of database of data, updated every .5 seconds, but only display a small part of the data at a time, depending of course on the scroll position?
==============================
Nothing to say.
|
|
|
|
|
As a possible step to improve performance, have you tried using LockWindowUpdate on the control while you are adding the new data to it, and then calling UnlockWindowUpdate after?
This stops the control trying to redraw itself on each event that modifies its content. Untill all the modifications have been done.
If you vote me down, my score will only get lower
|
|
|
|
|
Good tip.
==============================
Nothing to say.
|
|
|
|
|
I have a very small form on to a property page. If the user have not save the modification, I want to prevent closing property page ... but I can't do that.
Here is the code where I start the property page :
CTestSheet PropertySheet(_T("Test"),NULL,0);
PropertySheet.m_psh.dwFlags |= PSH_NOAPPLYNOW;
PropertySheet.AddPage(new CTestPage);
PropertySheet.DoModal();
delete PropertySheet.GetPage(0);
and I override OnClose handler in property page, in property sheet, I override OnDestroy in property sheet ... in vain ... doesn't function ... why ?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
