Dave,

Thanks for the info.  I'm only recently getting acquainted with using the windows key.  I'll play around with this on my computer.

EDIT:

I checked behavior of Qimage Ultimate and it behaves as you describe.  Window Key + left/right arrows works but the up/down arrows doesn't.

Jim H.

Terry-M,


As I said earlier, to each his own.  To me the maximize feature is the most useful.  I use the side-by-side feature rarely but I find myself using the reduce/maximize function on a regular basis.

Regarding the side-by-side operation, mburke gave a good example of how it might be useful (check book on one side and bank statement on the other).  To use the Snap function to do this is much easier than manually re-sizing the two windows.  The key to getting the side snap to work is to grab and drag until the mouse pointer reaches the edge of the screen.


You seem to be concentrating on the side-by-side feature.  I agree that one wouldn't use Qimage on half the screen.  The problem with Qimage is that the snap feature doesn't work at all and that is what Microsoft is saying.  Apparently Qimage has one of those "custom window behaviors".

Cheers,

Jim H.

Hi, All,

Since Terry-M says I was not clear in my original post (although I think I really was), what I am referring to here is the Windows 7 Snap feature which you can read about here:

http://windows.microsoft.com/en-us/windows7/products/features/snap


Fred, from your description following this quote, I can't tell whether you are saying the Snap feature works for you with QU or not.  I am happy to see that mburke confirms what I am saying.


Everybody has his preferences and that's why they let you turn Snap on or off.  Like mburke, I do use this feature quite a bit.  I don't use the "side-by-side" windows much but I do find it very handy to grab the top bar and pull it down to expose other windows or icons on the desktop and then to pull back up when I want full screen again.  This is, to me, easier then using the upper right buttons.  This is especially so for QU because the re-sizing buttons for QU are smaller and less easy to use than on most other Windows programs.

Obviously, this is not a huge deal because I have lived with it a while without inquiring. However, it would seem to me that Mike would want QU to follow standard windows behavior and it would appear that it doesn't.  I'm anxious to hear Mike's comment on this.

Jim H.   

Terry-M,

Perhaps I was not clear but you have missed the point entirely.

I have no problem with clicking buttons and dragging corners to re-size.  I was referring to the Windows 7 feature that allows one to maximize window size to fill the screen by dragging the top bar to the top screen edge and also to fill either the left or right half screen by dragging to the left or right edge.  On my installation this does not work with Qimage Ultimate.

Jim H. 

Mike,

I am running Qimage Ultimate on Windows 7 64-bit.  I notice that the window resizing behavior does not seem to follow the convention in which dragging up to the top of the screen causes the window to go full size and dragging to the sides fills half the screen.  Other programs do work this way on my computer, including your Profile Prism.

I did a search but did not find anything on the site that addresses this.  Is this what you intended or is this a minor bug?

Jim H.

Mike,

No mistaking what to do now!

You and Delphi done good!

Keep up the good work.

Jim H.

Mike,

I think you have hit on the solution to the stretch problem.  That should remove any confusion over calculating percent stretch.

As for programming languages, I had similar feelings about C as you did.  Having always used Fortran at work, I never could wrap my brain around pointers and assorted features.  I did Pascal and C programming at home for hobby purposes.  I really did like Pascal (Turbo and Borland) but never got comfortable with C.

Fortran has a reputation as being out of date compared to more modern languages but for engineering computation, it is still powerful.  The newer versions are now even incorporating some of the structured and object-oriented programming features of the more modern languages.  However, when I retired six years ago, I was still using the old non-structured stuff for the most part, not finding the the new features really necessary.  Old dogs and new tricks, you know.

Jim H.   

RayW,

Mike is going to kick us off his forum if this goes too far, but ...

Very early on I programmed in basic on a CPM machine.  Then I discovered Phillippe Kahn's Turbo pascal.  I thought it was wonderful, especially compared with basic!  I did home programming in pascal on DOS and Windows up until the advent of object pascal.  I also did home programming on Borland C.

Kahn's products have always impressed me.  Interestingly, I am now using a GPS navigation app on my iPad called MotionX Drive GPS which is a Phillippe Kahn product.  It is very good and I now use my iPad as my primary GPS navigator, supplanting my Garmin.

Essentially all of my programming at work was in Fortran, primarily simulation of dynamic systems in the aerospace industry.

As for punched cards, when I started Fortran programming everything was on boxes of cards.  We got our output on a big stack of paper and then plotted results by hand on graph paper.  Those were the days!!

Cheers,

Jim H.

Mike,

You said


I can't resist commenting on this.  The typical C and C++ programmer just revels in the tricky and sly shortcut.  He is always trying to compress the algorithm into the shortest and most incomprehensible code possible.  Therefore, he would favor your method.  The typical plodding Fortran programmer can't remember tricks and must start from first principles and therefore would favor my method.

Jim H.

Mike,

I think we can argue this all day and probably not agree on the best method.  Your approach certainly works but I am convinced that only a minority of people would use your method to calculate percent change whatever the situation.  In my opinion you should not tell users how to calculate the required percent stretch at all.  Better to just define precisely what the input requires and leave it to the user to use whatever method he prefers, either mine and RayW's or yours.

You are making an argument that your method is easier and simpler than mine.  I would argue that using your method is essentially using a mathematical trick that has the big disadvantage of basically ignoring the natural definition of percent change which is 100 times the fractional change where the fractional change is the change or delta from some base value divided by the base value.

In my experience it is better to remember a definition and do calculations based on that definition than to remember a trick that gives the same answer.  I argue, but you may disagree, that your method bears no obvious relation to the definition.

By the way, I do not subscribe to RayW's suggestion that your "view of reality" has been somehow distorted by Pascal programming.  I am a retired engineer who programmed in Pascal, basic, C, and Fortran (mostly Fortran) and I don't feel that my view has been distorted (although friends and family may disagree).  On the other hand, during many years of working with numbers, it never occurred to me to calculate percent change in the manner you suggest.

I think I can anticipate your rejoinder.  You are going to say that many Qimage users don't know enough about the definition of percent change to do the required calculation.  This is probably true of those who print on canvas.

Jim H.

Mike,

As the late, great Etta James sang "At Last"!  The answer has come along.

I'm glad we are on common ground now.  The only criticism I might offer after all this is that your method of using a ratio and then subtracting one and then shifting the decimal two places to the right, although simple, deviates from what people would normally do when asked to calculate a percentage stretch.  I may be wrong but my guess is that most would calculate it using the definition of percentage change (i.e. 100*change/base) instead of what might be regarded as somewhat of a mathematical trick.

And I said I was through ...

Jim H

Mike,

I'm going to make one more comment and then I'll slink away.

What got me started was your initial use of the 36/35.5 = 1.04 example instead of the usual calculation of stretch percentage that Ray and I seem to agree on.  This led Seder to ask if, when needing to stretch from 20 inches to 20.2 inches, he should put 1.01 into the input (20.2/20 = 1.01) .  You then said that using 1.01 is correct but it is clearly not.  This is partly what led me a little astray.

What I had not realized is that what you are saying is that you can use the ratio calculation if you use the fractional part of the result (multiplied by 100).

Example: Suppose you want to stretch from 40 inches to 50 inches.

50/40 = 1.25 ---> 0.25*100 = 25%

The more usual percentage calculation would be

100*((50 - 40)/40) = 25%

Voila, the same answer!!

A little algebra shows why this is so:

Let d = desired length

      r = resultant length

Then

      100*((d/r) - 1) = 100*((d - r)/r)

This little result had escaped me.

It's been fun!

Jim H. 

RayW,

Now we are making progress.  I agree with what you are saying regarding percent change, but


I would say it's more a matter of precise definition on Mike's part than one of semantics.  But, then that may itself be a matter of semantics.

I started all this because Mike used the 36/35.5 ratio in his initial example.  I can only assume that he had a temporary brain freeze because this is clearly not how one calculates either percent shrinkage or percent stretch.  It's a ratio and not a percent change.  I only jumped into this because Seder then was led astray and used the ratio as Mike seemed to be suggesting.  He asked Mike if he was correct and Mike responded that he was when he clearly was wrong.

I then made my initial 10% instead of 1% mistake but that was just a slip on my part and not fundamental to my argument.

After wandering around a bit, I finally looked at the QU box to be filled in.  If you hover your mouse over the box it says "Stretch the length by this amount" and it asks for a percent.  Therefore, for the intended 36-inch print that shrank to 35.5 inches, I would say that what Mike seems to be wanting is to stretch a 35.5 inch result to 36 inches.  I think this would properly require a "stretch" computed by

100*((36 - 35.5)/35.5 = 1.408%

If, on the other hand, Mike really intends the input to be the amount of "shrinkage" from what is intended, then since we want 36 but are getting 35.5, the shrinkage number would be

100*((36 - 35.5)/36) = 1.389%

Obviously this "semantic difference" is probably of no practical concern unless of course Mike really means to use the ratio.

Jim H

In my previous post I said

"The only way that I can see that I am incorrect is if the definition of percent stretch is really the ratio and not the usual percent change.  If that is the case then his initial example is wrong."

Just to clarify, what I meant is that I am wrong if Mike intended us to use the ratio in QU instead of the normal definition of percent stretch.  But if this is the case then he is being inconsistent in his first example.

Jim H

RayW said

"try again, Jim"

Well, I would like to hear more in the way of argument than that.

My main point is that normally when we refer to a percentage change we are not talking about a ratio of intended amount to result but instead to the resultant difference or delta divided by the base value.  In that case, Mike had the correct answer for shrinkage of 35.5 result for 36 intended.  He said the shrinkage is 36/35.5 or 1.4%.  His answer is correct but the method he is suggesting is incorrect.  The proper calculation should be

100*((36 -35.5)/36) - 1.389% which rounds to 1.4%.

36/35.5 = 1.014 on my calculator.

This lead Seder to do 20.2/20 = 1.01% which is clearly wrong.

So, rayw, I would encourage you to "try again".

The only way that I can see that I am incorrect is if the definition of percent stretch is really the ratio and not the usual percent change.  If that is the case then his initial example is wrong.

Jim H.