Welcome to our forums
Eddie
Something must have gone wrong with my build and upload so I have done it again.
Dan
I will make an note of the problem with the superscript alignment.
As a general rule, it is very difficult to fix alignment problems because, any changes that we make will probably break some existing code.
Sometimes one thinks that it might be easier to start again but we haven't got there yet!
Dan,
Every time I read one of your posts I learn something.
I am very aware of the problem of superscripts and subscripts, as these even catch me out in graphics programs like CorelDraw, Powerpoint and even MS Word, so I expect that Paul will struggle to improve things greatly in Clearwin+.
As far as positioning is concerned, you may find %rp and %ap (and I forgot %dy) to be horrible to use, but that is what they are there for. Some of the spacing issues may well be due to choices made at Salford/Silverfrost, but some are surely embedded in the design of Windows itself.
When I look at your examples, I am immediately struck by the complexity of the layouts that you have designed. I usually try to design things to work on a tiny netbook with an 800x600 screen, but equally, they have to work on monsters with 1920x1080 or bigger. If your default is bigger, you can space your controls out more, and this reduces the visual alignment problem. Sometimes you could solve the problem even with Clearwin's layout arrangements. For example, your image containing the text 'Set # of CPUs to use' etc. You have imposed the spacing of the %rd box containing 8 on the spacing of the %rb buttons. Apart from the fact that these are not ganged, and therefore the check box %`rb is preferred in the Windows UX guidelines, you could have taken this radio button out of the list and put it in an invisible box perhaps over on the right with the 'Set #...' text and selector.
I might have written it like this:
write(NUMBER, '(I1)') Number_of_CPUs
IA=WINIO@('# of CPUs to use out of '//NUMBER//' total&')
There is nothing to stop you changing the font size before using the %rd box, as that also affects alignment, and change it back afterwards.
For the more complex things like Greek and math symbols, sometimes it is better to draw them as a bitmap, and incorporate that.
If you let your radio buttons take their text after the symbol, the irregular spacing as in your lower example is very much less obvious. In this example, you could make great use of named boxes to divide things up, and you have space to put the radio buttons in a column on the left with the numeric values in a column on the right e.g.
WINAPP
OPTIONS (INTL, DREAL)
PROGRAM DAN_DEMO
INCLUDE <WINDOWS.INS>
iCentred = 0; iDebug = 0;
iPhone = 1; i911 = 0;
iGeom1 = 1; iGeom2 = 0; iGeom3 = 0;
Geom_Factor1 = 0.0
Geom_Factor2 = 0.0
Geom_Factor3 = 0.0
IA=WINIO@('%ca[End of Universe calculation?]&')
IA=WINIO@('%ob[named_l][One line]%nl&')
IA=WINIO@('%ob[invisible]%`rb[Slice centred]%2nl%`rb[Debug?]&',
& iCentred, iDebug)
IA=WINIO@('%2ga&', iPhone, i911)
IA=WINIO@('%3nl%rb[Phone Dan]%2nl%rb[Phone 911]&',
& iPhone, i911)
IA=WINIO@('%cb%ta%ob[invisible]&')
IA=WINIO@('%`rb[Use Geom Factor 1:] Geom Factor value 1 &',
& iGeom1)
IA=WINIO@('%~rf[initially_blank]&', Geom_Factor, iGeom)
IA=WINIO@('%2nl%`rb[Use Geom Factor 2:] Geom Factor value 2 &',
& iGeom2)
IA=WINIO@('%~rf[initially_blank]&', Geom_Factor, iGeom)
IA=WINIO@('%2nl%`rb[Use Geom Factor 3:] Geom Factor value 3 &',
& iGeom3)
IA=WINIO@('%~rf[initially_blank]&', Geom_Factor, iGeom)
IA=WINIO@('%cb%ff%nl%rj%6`tt[Apply]%tt[Cancel]%cb')
STOP; END
RESOURCES
1 24 default.manifest
It only matters that the vertical spacing is regular. Named boxes allow you to avoid putting the same text (e.g. 'One line') on each label. I am sure that my code example could be improved enormously. To summarise, I am suggesting that instead of wanting your controls to mainly line up horizontally or vertically, think of them in groups defined by boxes, and enforce your alignment & spacing only within any one box.
I hope that this is some help.
Eddie
Eddie,
thank you very much! Just now I saw your code. I'll test and play with it next week, and will try to integrate this in my code.
Best regards - Wilfried
Dan,
I fell foul of the length problem!
Named boxes allow you to avoid putting the same text ('One line' in this case).
If you forget about alignment in the whole window (dialog), but divide the controls into boxes, and enforce spacing and alignment only in the boxes, it works better. The more spacing you have, the less the vertical alignment matters.
I hope this is some help.
Eddie
Hi Wilfried,
The callback to any %gr or %dw area is likely to become huge. Mine tend to be divided up into subroutines. The first thing I do is to get the callback reason and the mouse position. Then I decide what to do. For some things (like a resize) I can forget the mouse position and just get on with resizing the window.
I also have a set of flags (F1) for each possible action in the region, and a set of flags (F0) for actions that have a beginning and end. The flags are set via the buttons in a toolbar/toolbox.
If an F0 flag is set, then I look to see if I am completing or continuing a particular action or cancelling it. I go through the F0 flags in the order from most likely to least likely. If it isn't one of those things, I do the same with F1 flags, again in the most likely to least likely order - to see if something is being started or if something can be done in response to a particular mouse event. The %gr callback routine only decides what to do: actually doing it is in a different subroutine for each action so that my brain can keep track.
My stretchy box example omitted the code for creating the rectangle in the first instance. Although I am very wary of full_mouse_interrupts (FMI) you probably can't do such activities without them.
It wouldn't take much more effort to make the stretchy box a 'bounding box' to some other figure, like an ellipse, and to stretch that at the same time. The final event would then be to hide the bounding box - which is just a matter of redrawing it one last time in XOR mode.
I am afraid that my code is rather 'pedestrian' by the standards of real computer scientists ....
Eddie
Paul,
Ever since I read 'The Monkey's Paw', I have been cautious about what I wished for. I knew that rounded corners for Clearwin+ boxes would be troublesome, and sure enough, there are lots of traps in this!
In the example I showed, there were 3 named boxes. As square-cornered, they work with %sy[3D_thin], but when [rounded] they do not (for obvious reasons, clearly stated in the ENH file). However, the numerals for degrees, minutes, seconds in the second named box (“Results”) are placed in %rd boxes, and when %sy[3D_thin] is removed, the outline round the %rd boxes goes with it, causing a vertical “Dan alignment” problem that I had not foreseen. I could not get the boxes back even with %co[data_border]. However, vertical alignment of whole lines is a simple enough problem to deal with , but what I could find no way of dealing with was that the numbers for degrees, minutes and seconds were left-aligned within those now invisible %`rd data boxes, and so the relevance of the degrees, minutes and seconds symbols was lost: it appeared like this:
0 °0 ‘0 “ instead of 0° 0’ 0”
The latter would have been clearer even with data boxes, but I was unable to right-justify the numbers, and it does matter more when the data boxes aren’t there. Once again, the problem isn’t insuperable, and knowing that it exists, I could convert the whole sequence to a string and output that – but it was an unexpected consequence.
The third named box (“Criticism”) is actually placed within an invisible box, in order to secure the proper alignment for the credits. As [rounded] operates on the outermost box (even when specified as applying to the inner, named, box), it obligingly gave me four visible rounded corners for the invisible box, but left the named box with square corners!
Curioser and curioser, when the program was minimised to the taskbar and then restored (Windows 7 64-bit), all trace of the rounded corners had gone – they were back to square, and the invisible box was completely invisible again!
Eddie
Eddie,
Let me say something in general, i always say here ones in a while, this time may be in a bit different way. With CWP we all learn from each other much more intensively then from, say, general Fortran part of the forum or any other, because we all have the same goal and subject while there we have very many ones not crossing our experience or not giving us large benefits. Due to that doubling amount of users will super-linearly intensity of interest. Hence CWP could be great catalyst of using of this compiler in the manner resembling the chain reaction, the more users → the more WOW feedbacks → the more users, or kind of exponentially. It just needs initial seed, the active promotion of it BY US, USERS, in all related sites. Should i say how this will be beneficial for all of us? The number of advanced options, speed of development, improvement, bug fixes etc of this compiler will dramatically increase because developers' pay will increase exponentially (while with all other compilers linearly and there are no incentives in all other compilers to grow their users base). CWP right now is just in its child's pants. Being further developed it has the potential to change Fortran and programming dramatically when we will not do coding but assemble code visually out of lego blocks of created libraries using often just the mouse.
Hi Dan,
You are spot on: Clearwin is a different trick from Fortran, as it contains aesthetics as well as programming. This section of the forum interests me most, partly because I don't care much for modern constructs - I'm an old dog, and they are new tricks - and often I simply don't understand what the person who posts is actually doing, or why they want to do it! I normally understand what people want to do in Clearwin - even if I don't know how to do it, and learn from others.
I always encourage folk to try the PE and to buy a licence. Without purchasers, FTN95 and Clearwin are dead in the water.
I know that you like skeuomorphic design, but the new paradigm in Windows 8 Metro has the potential to be a lot more suited to Clearwin+, and this may encourage some take-up. The problem is that most Fortran oldies haven't really understood the whole business of how Windows applications look and feel. I'm only just getting there, and I remember going to the launch of Clearwin back in 1992 (I think)!
I have a feeling that this thread is becoming overloaded with multiple sub-topics, don't you?
Eddie
I have had another go at %ob[rounded]. Please test today's beta upload.
p.s. A box can now be both rounded and scored.
Hi Eddie,
now I've used your idea and code for stretching a selected area and it works fine. So once again many thanks for your help!
Wilfried
Wilfried,
I'm really pleased that you liked it, but don't forget that Ian sorted out the XOR part so that it worked well. There is a benefit for me in doing things like this as I may be able to lose my fear of full_mouse_interrupts!
If you use this simple demonstration in production code, you will discover a problem. I used a very simple test about the left button. I did this deliberately, because testing coordinates is a much more obvious Fortran thing to do than sorting out the button presses! What I wrote probably won't work if the user presses Shift or Ctrl at the same time. If the mouse flags are IFL, then
IF (and(IFL,MK_SHIFT) .EQ. MK_SHIFT) THEN
ISHFT = 1
ELSE
ISHFT = 0
ENDIF
IF (and(IFL,MK_CONTROL) .EQ. MK_CONTROL) THEN
ICTRL = 1
ELSE
ICTRL = 0
ENDIF
... you can use the logical AND to determine if either of those keys have been pressed, also don't just test for 1 (left button) but sieve out the other button presses too (You might have different behaviour for them). I'm not good with these tests, so I do them once, and make some settings in integers that I can examine later, as in the example above. MK_SHIFT and MK_CONTROL are defined in the INS file.
Some suggestions I have for you are also that when I drew the node/handles, I drew them as circles. But you may have noticed, when I tested proximity, my test was in a square region!. You could draw handles other shapes, do other proximity tests, etc.
I also used 8 peripheral node handles: 4 corners, with free x-y movement; and 4 mid-sides, constrained to move only in x or y. If you use 4 corner node/handles, you can use the Shift or Ctrl modifiers to pull the shape into a general quadrilateral, or constrain the node to move in x or y (say), or use the right mouse button to keep it a quadrilateral.
You could also have a node/handle in the middle of the object which you could use to move it as a complete fixed shape in x, or y, or freely (again depending on Shift and Ctrl settings). I chose 8 node/handles partly because this might be familiar to you from the Paint application, but also it illustrated different behaviours for different nodes.
In Powerpoint, selecting an object draws control node/handles including one on a stalk that you can use to rotate the object. CorelDraw uses a second click on a node to select a rotatable mode, where the cursors are different. Moving a corner node rotates the object, and moving a mid-side node shears it (e.g. rectangle into parallelogram).
You need to consider the entire look and feel of your program, and the likely users, to see what settings to implement.
I hope that this is also helpful.
Eddie
(PS As I know you do finite element analysis, I also considered using shape functions to allow distortion of the shape as in Zienkiewicz's book, but it made the code too long. There is also then a limit on the amount of distortion before the element becomes ill-conditioned. You can also consider using area-select to pick up more than one node/handle or the whole object).
Paul,
I have had another go at %ob[rounded]. Please test today's beta upload.
Sorry, I missed this until this morning, and was away from my computer for a couple of days anyway. I had a go, and fine, it ignores the outer invisible box. It minimises and restores as it should.
But, using my settings of:
IA=WINIO@('%bg[btnface]%sy[3d_thin]')
.... I found the top right and bottom left corners appeared in white only, and this didn't look right to me. In the interests of trying to be helpful, I also looked at the other 3d options, e.g. 3d_raised, 3d_depressed and plain 3d, and while the white corner in these positions sounds as if it might be right to do the shading, I think that you could forget that attempt and it would look better - just do it in the default colour (black in my example).
The rounded corners certainly make the application look more modern, and in my various attempts I was impressed at the look of the %sy options I haven't used.
Thanks for this effort.
I sometimes feel that the bottom of a box is too close to what goes before, and Clearwin+ outsmarts me if I just put in a blank character. However, if I put in a character (such as a full stop) in the right colour, I can outsmart the box to give me more space! (The full stop even just about works if I forget to set its colour).
Eddie
Eddie,
to get info about the mouse I use
mouse_x = clearwin_info@('GRAPHICS_MOUSE_X')+1
mouse_y = clearwin_info@('GRAPHICS_MOUSE_Y')+1
m_flag = AND(clearwin_info@('GRAPHICS_MOUSE_FLAGS'),31)
m_info = adjustl(clearwin_string@('call_back_reason'))
and then
if (m_info(1:12) .eq. 'MOUSE_DOUBLE')
* m_info(1:20) = 'MOUSE_LEFT_CLICK '
if (m_info(1:16) .eq. 'MOUSE_LEFT_CLICK' .or.
* m_info(1:17) .eq. 'MOUSE_RIGHT_CLICK') then
c
c ... something
remember = m_flag
c
else if (m_info(1:18) .eq. 'MOUSE_LEFT_RELEASE' .or.
* m_info(1:19) .eq. 'MOUSE_RIGHT_RELEASE') then
c
c ... something else
m_flag = remember
c
end if
I found some values by testing - for instance, pressing the central mouse wheel gives the value 8 for m_flag.
In my image display I use the mouse wheel to set the zoom factor. This can be done with something like
wparam= clearwin_info@('MESSAGE_WPARAM')
i = hiword@(wparam)
... then with i the zoom factor is calculated.
My experience is that with Clearwin+ and WinAPI and a lot of time of trial and testing (and also colleagues like here in the forum!) it is possible to do nearly everything with Fortran under Windows.
Best regards and a nice evening Wilfried
Wilfried,
I never experimented with the mouse wheel for zooming, I always chose (initially) to zoom in steps, or (later) to zoom to a selected area. I shall have to try the wheel.
I didn't know if I made it clear, but the mouse flags are a combination of all the settings, and if you can be sure that the user only does one thing, you can test for that. If the user does more than one thing together, you need to sort out precisely what is going on (hence the logical AND function) - otherwise, you are doing much the same as I do (I think that this is an engineer's response, rather than a computer scientist's method!).
I found full_mouse_interrupts (FMI) problematic some years ago, and use them only rarely through fear (probably). Although John Campbell gave me a lot of help, in retrospect I think I got in a mess because I expected the same behaviour with and without full_mouse_interrupts, and in some important respects, it is different. For example, when you get the callback reason MOUSE_LEFT_CLICK, without FMI it means the left mouse button has been depressed AND released, where as with FMI, it only means depressed only - released give a different callback reason! If you interrogate the mouse flags you decide for yourself what the mouse button status is. This isn't very clear in the documentation, although it is best described in the CHM file in the 'library reference' under 'CLEARWIN_STRING@'.
Eddie
Eddie,
I always use full_mouse_input within the %gr graphics area. Is this what you mean saying full_mouse_interrupt? The behaviour of callback reasons like mouse_left_click are not modified if I press shift and/or ctrl, therefore I had no problems with getting mouse parameters up to now.
Wilfried
If you hold down the CTRL key whilst using the mouse wheel then you are often provided with a zoom. This includes Google Chrome (that I am using at the moment) and recent versions of Plato (not sure when I added this).
You get the same effect from a pinch movement on the mouse pad or on the screen of a tablet (i.e. the CTRL key state is added automatically by the system).
Next question: is there an easy way to get the CTRL key state in ClearWin+ when processing a mouse wheel event? If not then I need to add something.
Hi Wilfried,
You are correct: it is the automatic behaviour of my fingers without the connection of my brain that writes 'interrupts' instead of 'input'. Many decades ago, we were not insulated from the (optional) mouse driver software by Windows. An 'interrupt' was generated by the mouse software every time it moved or was clicked, so that the cpu could save what it was doing, respond in some way, and then return where it left off. Assuming that deep down the PC is still working much the same way, the mouse message in Windows is probably responding to an interrupt. Paul would know.
If you don't use FMI (input, not interrupt!) then you get MOUSE_LEFT_CLICK on the button release, not the button press. Now I understand the difference, I may lose my fear of FMI!
Eddie
Paul,
The effect you describe also works in Internet Explorer. In view of this, it is probably an emerging standard.
Are Shift and Ctrl button presses what is meant by extended mouse events (http://msdn.microsoft.com/en-us/library/cc240587.aspx) and equivalent to buttons 4 and 5? (Rhetorical question - I wouldn't understand the answer!) - in which case they should be reasonably easy to sort out from the flags.
It would be very useful to add something at some point to be able to decipher a pinch, stretch or swipe movement - eventually. At the moment I think your suggestion to help the Fortran-only speaker sort this out is an excellent one. It would be a great gesture (pun intended!)
(Another rhetorical question: if a pinch = Ctrl + Mouse wheel, is a 'negative pinch' Ctrl + negative wheel motion, and if so, what is mapped to Shift+mouse wheel etc?).
If Windows 8 tablet support is contemplated, then it would be very important to be able to determine if a physical keyboard was connected.
Eddie
I have added the following information to cwplus.enh.
%^gr[full_mouse_input] already provides the callback reason 'MOUSE_WHEEL'. When this event is processed, mouse data can be obtained by calling clearwin_info@ with any of the following arguments: 'GRAPHICS_MOUSEWHEEL_ROTATION', 'GRAPHICS_MOUSE_FLAGS', 'GRAPHICS_MOUSE_X', and 'GRAPHICS_MOUSE_Y'.
A mouse wheel event combined with holding down the CTRL key is usually interpreted as 'Zoom in' or 'Zoom out'. Also when
a pinching movement is used on a mouse pad or on a touch sensitive screen, the system translates this to a mouse wheel
event with the CTRL key held down. To test for the CTRL key state, take the bitwise AND of the mouse flags with MK_CONTROL
(MK_CONTROL has the value 8).