|
That's great! Thanks a lot for your help, and I'll let you know how things go.
|
|
|
|
|
This is my first post so please be kind.
I have a project that requires the locale for the current session to be set to something different than the system setting, e.g. system is American English but the session needs to be German. The program uses setlocal.c aand related routines installed with VS2005.
This works well for most languages. The problem is that some locales/languages cannot be set with this method per MS (
|
|
|
|
|
CliffRat wrote: The problem is that some locales/languages cannot be set with this method per MS
If this is a published restriction I am not sure what you expect from this site.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
Silly me...
Iguess I thought someone might know of another method or possibly a workaround to this one.
|
|
|
|
|
The [setlocale] function.
The code below sets the current locale to "Germany".
#include <stdio.h>
#include <locale.h>
#include <time.h>
int main(void)
{
time_t ltime;
struct tm *thetime;
unsigned char str[100];
setlocale(LC_ALL, "German");
time (<ime);
thetime = gmtime(<ime);
if (!strftime((char *)str, 100, "%#x",
(const struct tm *)thetime))
printf("strftime failed!\n");
else
printf("In German locale, strftime returns '%s'\n",
str);
setlocale(LC_ALL, "C");
time (<ime);
thetime = gmtime(<ime);
if (!strftime((char *)str, 100, "%#x",
(const struct tm *)thetime))
printf("strftime failed!\n");
else
printf("In 'C' locale, strftime returns '%s'\n",
str);
}
|
|
|
|
|
Thanks for the suggestion but that is what is currently being used.
The problem is that some languages, and the codes are clearly documented, have a codepage value of 0 (zero). Some of these languages need to be set for the session but are rejected because a zero codepage is not handled in the code.
I need a workaround to programmatically change to these 0 (zero) codepage languages.
HELP!
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
