|
Thanks, it does the work, but this isn't a parametrized query.
I want to know how to pass parameters to a view.
|
|
|
|
|
Ahh, that's a different request! You'll want to read this article.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
For a technical drafting program, i need to draw truetype fonts with total control on their height : for example i want a text of exactly 10mm high.
The problem is in interpretation of height; for truetype fonts, this height is made of 3 arts : Descent (part under the baseline), Ascent (part over the baseline), InternalLeading (some space above the character). All these values are returned by pDC->GetTextMetrics() when you have selected a font in the pDC.
In my case, when i say i want a font 10 mm high, it means a font whose characters above the baseline (such as digits) will be 10 mm high. This convention is used by programs such as Autocad, MicroStation, ...
For creating a CFont object, you have to fill a LOGFONT struct with the properties of the font, such as font name, height, weight, ... But as said before, the height specified here include descent + ascent + leading. Here is how i try to get what i want :
CFont *pOldFont, newfont;
TEXTMETRIC Metrics;
LOGFONT lf;
double HcarFromFont, HcarWanted;
memset(&lf, 0, sizeof(LOGFONT));
strcpy(lf.lfFaceName, "Arial");
// HcarWanted is the required height (say 10 mm) converted in pixels;
// the height must be specified in logical units, which are pixels because the the current mapMode is MM_TEXT.
HcarWanted = 10 /* mm */ * ConversionFactor; // ConversionFactor translates mm in pixels
// set the height - this is just a first try :
lf.lfHeight = - (long)HcarWanted; // note the minus sign, this is normal (see doc. for LOGFONT)
... // set others font properties
newfont.CreateFontIndirect(&lf);
pOldFont = pDC->SelectObject(&newfont);
pDC->GetTextMetrics(&Metrics); // get metrics (in pixels) for the font just created
// read the current height for ascent part :
HcarFromFont = Metrics.tmAscent - Metrics.tmInternalLeading;
// here is the trick : the height of the ascent part is of course smaller than the required height;
// so i correct the total height (lf.lfHeight) so that the ascent part grows up to the required height :
lf.lfHeight = (long) (lf.lfHeight * (HcarWanted / HcarFromFont));
// example : let's say that HcarWanted is 100 pixels and that GetTextMetrics()
// returned HcarFromFont = Metrics.tmAscent - Metrics.tmInternalLeading = 60;
// so the new lf.lfHeight is multiplied by * 100/60 = 1.66
newfont.Detach();
newfont.DeleteObject();
newfont.CreateFontIndirect(&lf); // recreate the font with the corrected height
pDC->SelectObject(&newfont);
// the following lines just check that the new height of the ascent part is very near of the required height :
pDC->GetTextMetrics(&Metrics);
HcarFromFont = Metrics.tmHeight - Metrics.tmInternalLeading;
Problem : the resulting height on screen is near the required height but there is still an error up to 20 %; for a same specified height, some fonts are smaller, some are bigger.
JPG
|
|
|
|
|
Have you considered working in a different mapping mode, for example, MM_LOMETRIC?
If you want to implement printing, using such a device-independent mapping mode will seriously simplify your code.
One thing that will bite you is that MM_LOMETRIC has the y axis increasing from the bottom of the screen to the top, unlike MM_TEXT which is the other way round. By default, the (0, 0) position is still in the top left of the window.
You can implement zooms and pans simply by modifying the window and viewport extents.
For more information, see Mapping Modes and Translations[^].
|
|
|
|
|
I have made tests with 2 mapping modes :
on screen : mapmode = MM_TEXT : 1 logical unit = 1 pixel
when printing : mapmode = MM_LOMETRIC : 1 logical unit = .1 mm
The problem stays independently of the map mode; i don't think it's a problem
of map mode, since for a same mapmode and a same lfHeight (in the LOGFONT struct),
the effective height of the text will vary with the font.
And my problem is not only that the height changes with the font : for a given font i want that the height of the 'ascent' part of the font is precisely 10 mm, and i can't get that. For example i want digits (these characters have no descent part) of exactly 10 mm.
(Of course i don't set lfHeight = 10, but i apply a factor converting mm to pixels; i know this factor is correct, i use it for drawing lines).
|
|
|
|
|
Hi,
I far as I can remember there is something like a negative height. When the height in the logfont structure is positive it is the height with the leading, when the height is negative it the cell height. But I do not know if it's just the ascending or the ascending+descending.
I vaguely remember that the TEXTMETRICS structure has members for ascent descent and so on.
So for your code the line
HcarFromFont = Metrics.tmAscent should do what you need;
Regards
G. Steudtel
|
|
|
|
|
yes indeed I use a negative lfHeight, it means that height is the character height (ascent + descent, including an internal leading); a positive lfHeight would mean the cell height (= character height + external leading).
G. Steudtel wrote:
HcarFromFont = Metrics.tmAscent should do what you need
so I presume I write :
lf.lfHeight = -HcarWanted; // first try : HcarWanted = 10 mm (in pixels)
font.CreateFontIndirect(&lf);
pDC->SelectObject(&font);
pDC->GetTextMetrics(&Metrics);
HcarFromFont = Metrics.tmAscent;
lf.lfHeight = -HcarFromFont;
font.CreateFontIndirect(&lf);
But don't forget that CreateFontIndirect(&lf) will consider lf.lfHeight as the total character height, how can it known it's meant to be the ascent height ?
Or is there something i didn't grasp ?
Nevertheless I did test the above code : it does not work : the font is now much too small; suppose the initial height was 10 mm : say 6 mm for ascent and 4 mm for descent; so with the 2nd assignment of lfHeight, i will ask a font whose total height is 4 mm.
|
|
|
|
|
Hi,
Sorry that I made it too short. Off course if you take a smaller value you get a smaller font. The fault is by me for not thinking any further.
Two approaches:
1) In a loop increase the height of the font until tmAscent becomes 10.
2) HcarFormFont = INeededHeight*Metrics.tmHeight/Metrics.tmAscent; with iNeededHeight being a constant of 10 ( or what ever height you need).
I'm not so sure about the calculation but the ratio of height to ascent should be the factor to increase the height of the font. Also you should do some casting to double and back to integer to minimize rounding errors. But basically the second method seems reasonable.
Regards
G. Steudtel
|
|
|
|
|
In my first code, i did a similar interpolation that the one you suggest.
HcarFormFont = INeededHeight*Metrics.tmHeight/Metrics.tmAscent.
Nevertheless, using your formula or mine, the results are very near, and on screen the font looks either too small, either too big (it depends of the font).
Note that, curiuously, after having set the height with the interpolation formula, if i request again the metrics with GetTextMetrics(), i see that the height of ascent part is now equal (or very near) to the initial height i requested. So the formula seems to work, and yet on screen that's not OK...
Thanks,
JPG
|
|
|
|
|
For any office document and many other documents as well, you can edit the document's set of properties by right clicking the document's icon, and selecting the summary prop-page. There are for instance etries like "Document title", "Comments" and "Keywords".
In my code, I would like to access this information. That is, given a filename, I want to check if the correspondning file has an entry "Comments" and reads its value.
Can anyone with this knowledge share some hints or,  even better an example?
Regards // Jonas Pettersson
|
|
|
|
|
|
Thanx Michale for your help! It got me almost there... I have now extracted the information I wanted from all the Office documents in my application.
The thing is that I also need to do the same thing for a bunch of JPEG-files. Reading the article You proposed, I understand that IStorage and IPropertySetStorage only applies for compund documents, such as the Word documents You helped me inspect. The JPEG files aalso have properties like this - is there another way to access their properties ? Or is their properties stored elsewhere than in the file?
Once again, thank you 
Jonas Pettersson
|
|
|
|
|
Hello all, I'm an engineering student looking to go into control systems engineering and automation.
And just because I'm so interested in the field, I've started working on a ride control system (theme park ride) model written entirely in c++. I've designed and written the code for the vehicle, zone, and track objects.
Now,
My current plan is to have ride vehicle motion be powered by a near-infinite loop, with the program going from zone to zone checking zone status and advancing vehicles if certain conditions are met.
Heres a quick outline of how it basically works
Say we have a vehicle, called veh1. veh1 is located at zone 1 on the track. Now, zone 1 has its own characteristics such as integers timeinzone and zoneclearance. timeinzone is the minimum number of milliseconds the vehicle has to spend in the zone before it is able to advance to the next zone. zoneclearance is the number of zones that must be unoccupied ahead of the current zone for the vehicle to be advanced. So, back to veh1, the control loop checks zone 1, sees that veh1 is present, checks how long veh1 has been there (time at zone entry is also stored), and if a move is to be made, it checks the following zones (to comply with zoneclearance) before it gives the go for veh1 to move.
Every zone can have different values and requirements for advancement. There are also certain maximum values and vehicle safety zones that will return errors or stop all vehicle motion if they are intruded.
And, the help I need
I dont think the way i'm doing it right now is very efficient. I was wondering if there was another method to go about this. Keep in mind that I know only console c++, ZERO MFC.
In a perfect world, each vehicle would almost be its own pseudo-sub-program, and evaluate the conditions on its own. Can I do this in C++? There would be several vehicles, in a predefined environment, and they would decide "on their own" what the next logical move would be and send the information to the main control or user console. User intervention would only be required on errors, and all vehicles could send messages to the console, or even to a log file. It would be somewhat event-driven. I suppose its a level of artificial intelligence too. Except that there will be several "robots."
Any help or comments would be appreciated. Even the "YOU SHOULDNT BE WRITING THIS IN C++" comment is welcomed, just tell me what language you feel would be better.
|
|
|
|
|
All signs seem to point to mfc, to use multithreading and event handling.
Comments?
Looks like I'm going to have to bite the bullet here and learn mfc. Any recommendations? Advice? Books? Sites?
|
|
|
|
|
immanis wrote:
All signs seem to point to mfc, to use multithreading and event handling.
Comments?
[/EDIT Because I did not see that you answert yourself]
Here it goes:
If you have to learn anyway, what about a real framework?
wxWindows, QT if you wants to stay platform independent.
.NET or WTL/ATL if being tied to microsoft platforms is OK.
Biggest question I see here is:
Is Windows capable of doing this near-realtime type of stuff? Or would you better look into a different OS? Client server connected via HTML to have the best of both worlds?
Who is 'General Failure'? And why is he reading my harddisk?!?
|
|
|
|
|
From the computing standpoint, the overall strategy for a system like this is typically: 1) collect current state data, 2) evaluate system conditions, 3) provide control output. The collection of data from your vehicles and zone sensors already seems to be handled, so you should know what variables you have that define the system "state." The output of control back to the vehicles or to zone-changing controllers is also a finite set of items, and you should know what those are and how they contribute to the system state.
The logic for evaluating the current system state to determine what the next state should be can be described by ... a state transition scheme. Whether this is a large and cumbersome diagram, or a set of "rules," doesn't really matter. In the field of artificial intelligence, you can create a set of if...then rules to describe input conditions that affect output control, and this is a perfectly good method of determining your logic.
When it comes to programming all of this, sure, you could use a rule-based interpretive kind of language, or code the logic into methods within a class, distinguishing of course between vehicle objects, zone objects, input sensor objects, output controller objects, etc. The overall control of these objects, and their interaction, may become a bit messy, depending on how your control logic is formed, because many times the control logic spans many objects and any individual object may not have visibility over the state of other objects. Coordinating the interaction of these separate objects that need visibility of other objects' state can be tricky, and another approach may make more sense.
If you want each object to retain its independence and be an instance of a class, then you will need other classes that have visibility over all these other objects - the "business rules" class, for example. This is where you would put the control logic.
While timing is another consideration, typical Windows environments are able to keep up with a continual stream of inputs and outputs. But, if you depend on microsecond level timing, then Windows may not be the best choice, as the "real time" aspect isn't there. You don't have precise control over process timing, so by definition Windows isn't "real-time." It may be fast enough to keep up, which then makes it operate in "real-time," but this depends on how tight your time frame is.
Is any of this dependent on MFC? No. There are much larger issues to consider. If there is going to be a user interface, either for monitoring or control, then MFC would certainly provide some answers. But, again, there are other issues to consider.
That's my two cents worth.
Dave
"You can say that again." -- Dept. of Redundancy Dept.
|
|
|
|
|
David Chamberlain wrote:
typical Windows environments are able to keep up with a continual stream of inputs and outputs.
As far as I have heard from the engineers in our company, their main problem with windows is not the typical reaction time. With a modern CPU and memory you can get good typical reaction times, but you still have outliers where reaction is much slower.
Depending on the problem, this may be a knockout criterion.
So, while windows may provide a good typical reaction, it can not not guarantee a maximum reaction time.
But I am not an expert in real time programming (not at all) so please ignore me
Who is 'General Failure'? And why is he reading my harddisk?!?
|
|
|
|
|
jhwurmbach wrote:
you can get good typical reaction times, but you still have outliers where reaction is much slower.
You (and they) are absolutely correct. One of the primary factors in real-time programs is to be able to guarantee (and therefore predict) response times. Windows can't do this.
In the sense of real-time meaning "fast enough," Windows typically can respond to be able to meet the requirements. But in anything that is time-critical, well ...
Dave
"You can say that again." -- Dept. of Redundancy Dept.
|
|
|
|
|
"The overall control of these objects, and their interaction, may become a bit messy, depending on how your control logic is formed, because many times the control logic spans many objects and any individual object may not have visibility over the state of other objects. Coordinating the interaction of these separate objects that need visibility of other objects' state can be tricky, and another approach may make more sense."
Just a wee bit messy indeed!
In the real world, control systems like these consist of multiple plcs and hardware error checking, etc. This program is meant to be a model, so someone could set certain variables into the system, and have the computer run at accelerated time to see what the long term result would be. Later on, I want to add a vehicle capacity component. We'd be able to get a riders per hour count (based on real world boarding averages), and then say, change a dispatch interval, or change a rule somewhere and see what the longterm effects on rider counts would be.
Back to the ride control system
I think the best design would make the vehicles their own individual processes. A main "dispatch" process would give vehicles a "go" to proceed into the ride. The vehicles would also be able to fire events to the dispatch, and the dispatch would respond with either a user message or response broadcast, or both.
I'm thinking the logic and rules for movement should be included in the environment, not the vehicle itself. The vehicles own logic and rules pertain to whether or not it will "listen" to a dispatch command. For example if a vehicle is powered down, it is still exists in a zone, but will not respond to a "go" from dispatch. It may still respond to a "power up" command from the user.
There also has to be a continuous "go" broadcast from the dispatch process to all zones. And that broadcast should have the ability to change to "nogo", "pause" or "stop" depending on either user input or as a response to an event. The dispatch could take an event such as a vehicle taking too long to exit a zone, or intruding on a safety zone and broadcast "nogo" to all vehicles, then prompt the user for appropriate action.
I'm off to school, more discussion later on.
Thanks to everyone who has responded so far.
|
|
|
|
|
immanis wrote:
I think the best design would make the vehicles their own individual processes.
Having done several simulations, I want to caution you against implementing your simulation as if it were a real system, and by that I mean that each vehicle being a process is an implementation detail and not an aspect of what you are trying to simulate.
What?
Your simulation model really consists of sensor inputs, processing (state transitions), and controller outputs, where the sensor inputs and controller outputs are "simulated" as opposed to being connected to hardware. To simulate this process flow, you can make a set of processes that each need to react/respond to a controller process, or you could put each vehicle instance in a list of vehicles. On each simluation cycle, you simulate the acquisition of new inputs, iterate through your vehicle list to see what changes they need or what effect the new inputs have, and then you simulate the outputs, by updating the "state" of your world model. It's a very cyclic process: input, process, output (and the time frame of each simulation step is determined by you and is not at all affected by Windows). That is a much simpler implementation than interacting processes, and while I would argue that the simpler implementation is preferable, there is no impact to the underlying simulation that you are trying to evaluate.
When it comes to crunch time, you don't want to have to worry about the implementation as much as whether the control logic works right, and your ultimate goal is the evaluation of a set of input parameters on the performance of the ride (safety, customer throughput, etc). In fact, if you can define an evaluation function for the system "state," then you could use a genetic algorithm approach for finding the best set of input parameters that maximizes or minimizes your evaluation function.
"Yeah ... that's it ... and maybe you could get Loni Anderson to help. Yeah ..."
Good luck,
Dave
"You can say that again." -- Dept. of Redundancy Dept.
|
|
|
|
|
Youre right. Making each vehicle its own process is roughly how a real world implementation works, in fact, each vehicle has its own cpu, sensors, and wireless network connection, etc. It thinks for itself. And youre probably right that I shouldnt make the simulation this way. In the real world, the vehicle has to deal with many more variables; variables that would be difficult (if not impossible) to model accurately (such as wheel slippage, motor over/underspeed, brake failure, etc).
But, once I get all the vehicle movement issues down, I do want the program to resemble a real world ride system in many aspects. I dont want it to be a black screen that asks the user for the values to 20 variables, then after a couple seconds, returns the guests per hour. I want to have a live track layout with vehicle location indicators, I want the user to be able to initiate vehicle stop and start commands, and I want the user to be able to change certain settings "on the fly" such as dispatch interval and vehicles on track. I also want there to be different operational modes, such as manual mode, auto mode, test mode and maybe passive mode.
Manual mode would require all vehicle movement inside the station (boarding area and dispatch) to be commanded by the user(through the control system). After the user dispatches a vehicle into the "show" area of the track, vehicle control is given to the iteration system. When the vehicle returns to the station, it will not move unless it is ordered by the user (indirectly through the control system).
Auto mode would be the long term simulation mode, where time could be accelerated, and the station vehicles would be advanced automatically (based on real world load time averages).
Test mode would be where timeinzone and zone safety settings could be modified, to see how the vehicles would behave in a different track environment.
Passive mode is something different. In passive mode, the ride operates in the background, and the user is focused on rider grouping and vehicle load times. The only information displayed would be related to capacity and ride utilization.
Its essentially "The Great Ride Control System Game."
Any thoughts or comments?
"Your simulation model really consists of sensor inputs, processing (state transitions), and controller outputs, where the sensor inputs and controller outputs are "simulated" as opposed to being connected to hardware."
I've gotta write that down, because that is a perfect description of what I'm doing. The sensor inputs are essentially booleans. When the program is done, one should be able to apply the same logic to a real world hardware implementation; instead of a boolean being defined by a virtual vehicle movement function, it will be defined by a sensor, a physical circuit being open or closed.
You really hit the nail on the head there. Thanks for helping to clarify the design in my mind, and on my giant whiteboard.
|
|
|
|
|
immanis wrote:
In the real world, the vehicle has to deal with many more variables; variables that would be difficult (if not impossible) to model accurately
This is exactly the basis for an object oriented simulation, since each object can be modeled at different levels of detail. Initially, things will be fairly coarse, vehicle motion will probably be simple movement to a new (x,y) location. Later on, you can make it more detailed, and include acceleration, friction, etc.
immanis wrote:
I want to have a live track layout with vehicle location indicators
So, now you're talking about visualization and how the display of the simulation data becomes usable to a user. I recommend being able to log the simulation states to a file so that later on they can be replayed, perhaps against 2 or more sets of control logic to see which one is preferable. Having controllable inputs becomes critical in simulation design and testing.
immanis wrote:
Auto mode would be the long term simulation mode, where time could be accelerated, and the station vehicles would be advanced automatically
Remember that the time it takes for the computer to simulate the advances from one state to the next will most likely be much faster than how you want that displayed to the user. One strategy would be to increment your local time counter, advance the simulation to the next state, wait for the clock time to catch up, and then display that new state. In this way, user inputs could affect the environment, and the display proceeds at "real" time. For auto mode, to monitor what is going on, you can still provide the display but just not wait for clock time to catch up. Increment time, advance states, display versus increment time, advance states, wait, display.
With operator input being required in certain modes, you could also use this as a training aid and help operators learn what happens when they screw up the schedule, or how to maximize customer throughput.
And the display object can be arranged such that sometimes vehicle movement is displayed and at other times operational parameters are displayed, such as average times, delays, etc.
Overall, what you are describing is called a man-in-the-loop simulation, if you are counting on someone to control the vehicles. At some point, you could also connect some of the hardware sensors or controls and have a hardware-in-the-loop simulation. Both MITL and HWIL simulations are quite useful in many professional (job, paying) areas, so congratulations on being involved.
Dave
"You can say that again." -- Dept. of Redundancy Dept.
|
|
|
|
|
Thanks for the advice, it's good to talk to people who know what theyre talking about (although I really dont).
This project is in a pseudo-hiatus-replanning stage now, because I need to learn mfc. I dont think I can learn mfc by doing. I think its important to have a good overview of the capabilities of mfc before I start to use one of its functions.
Any suggestions as to what books to get as a beginner to mfc? Any books or resources (both online and in print) that deal with c++ in control systems?
Thanks again
|
|
|
|
|
immanis wrote:
This project is in a pseudo-hiatus-replanning stage now, because I need to learn mfc. I dont think I can learn mfc by doing. I think its important to have a good overview of the capabilities of mfc before I start to use one of its functions.
While I don't understand your ... fascination ... with MFC, this seems to me to be a classic case of "paralysis by analysis." You can't learn MFC by using it? What's up with that? With MFC being a toolkit for implementation, you still have a lot of design work to do. Remember the old addage about design being what you're going to do and implementation being how you're going to do it. You seem to be stuck on MFC, which is much further down the road from where you are now.
Go get a book, almost any book, on MFC. Start reading, start absorbing. But don't let that hold you up on the design. You seem to have a good understanding of what is needed in the application, and you seem to have a good understanding of what is wanted. The organization and architecture of your classes and objects, the rules for the control logic, the state transitions, the inputs and outputs, all have to be laid out in a nice fashion. Use UML diagramming to help keep it straight and help review the essential design elements.
The implementation will come along, and you can slowly add elements of MFC if you want. You may find that you can do what you need without MFC, and if that turns out to be the case, then all your wasted hand-wringing over not knowing MFC will be useless. Maybe MFC isn't the tool of choice for the environment where you want to deploy this software.
You really seem to have a good handle on this project. Just don't let the relatively insignificant issues be the ones that hold you up.
Dave
"You can say that again." -- Dept. of Redundancy Dept.
|
|
|
|
|
David Chamberlain wrote:
While I don't understand your ... fascination ... with MFC, this seems to me to be a classic case of "paralysis by analysis." You can't learn MFC by using it? What's up with that? With MFC being a toolkit for implementation, you still have a lot of design work to do. Remember the old addage about design being what you're going to do and implementation being how you're going to do it. You seem to be stuck on MFC, which is much further down the road from where you are now.
I want to be able to use MFC's functions for time, multithreading, and event handling. And later, its display functions. I dont even quite know what they are or how they work, but they look good on msdn. I know I can do all three of these in normal c++, but eventually I want this application to leave the console world, and have a relatively easy user interface. I dont want to sit and convert my application down the line (which people have told me can be a troublesome task). Some people have advised me to just add the mfc functionality I need to my existing application. The problem is, I'm not quite clear how to do that either. Everytime I try to include some mfc header files and define some mfc variables, I get massive errors.
You mentioned UML diagramming, and quite frankly I know nothing about what it is or how to use it. Right now I have a whiteboard filled with boxes, lines and arrows. What exactly is it, and how can I get started?
One of my professors is going to let me borrow an intro to mfc book. Hopefully that will be enough.
David Chamberlain wrote:
Go get a book, almost any book, on MFC. Start reading, start absorbing. But don't let that hold you up on the design.
Oh I cant seem to pull myself away from this program. I dont think it'll hold me up on design, it'll probably just help me identify what specific functions are needed to do what I want to do in my design. I shouldn't have said the project is on hiatus for me to learn mfc, I meant to say actual coding is on hiatus. Design is going on constantly. Design is the best part of the application development process, because everything works the way its supposed to on paper or in your brain. There are no unresolved externals in the design stage. 
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
