Hi Paul,
I would very much like to have the posibility to nudge the position of controls by using the arrow keys.
Maybe it could be something like in VB.....
1. Arrow keys alone moves focus amongst the different controls.
2. Shift + Arrow changes the size of a control
3. Ctrl + Arrow moves a control
If 'snap to grid' is enabled it should move and size with increments according to the grid size. If not it should use increments of one.
It would also be nice to be able to move and size by one even if 'snap to grid' is enabled. Perhapse using alt + arrow? if so then 'snap to grid' evaluaton is not necessary for movement only size.
Also on the format menu it would be nice to have a option called 'size to grid' which would size a control to the closet grid possibility. Is it 4.5 wide this would make it 6 wide if the grid was 6x6.
Another option in regards to alignment would be the 'align to grid' which should move the control to the grid. Say a control is located at 4.5 left when using 'align to left' it should move to 6 left since 6 is closest 6x6 grid alignment.
Perhaps a UI check tool would be possible. It would be a tool that checked the design according to the UI Guide:
- Space to window edge 7 dialog base units
- Space between all controls 4 dialog base units
- Height of controls 14 dialog base units
- horizontal and vertical alignment
(and others if necessary)
Best regards,
Gian
Quote from: Gian KolbjornsenMaybe it could be something like in VB.....
1. Arrow keys alone moves focus amongst the different controls.
2. Shift + Arrow changes the size of a control
3. Ctrl + Arrow moves a control
This is the way it works now, doesn't it????? On my system it works exactly like you described.
QuoteIf 'snap to grid' is enabled it should move and size with increments according to the grid size. If not it should use increments of one. It would also be nice to be able to move and size by one even if 'snap to grid' is enabled. Perhapse using alt + arrow? if so then 'snap to grid' evaluaton is not necessary for movement only size.
I agree. I will have to implement this.
QuoteAlso on the format menu it would be nice to have a option called 'size to grid' which would size a control to the closet grid possibility. Is it 4.5 wide this would make it 6 wide if the grid was 6x6.
Another option in regards to alignment would be the 'align to grid' which should move the control to the grid. Say a control is located at 4.5 left when using 'align to left' it should move to 6 left since 6 is closest 6x6 grid alignment.
Both very good ideas. I'll add them to my list.
QuotePerhaps a UI check tool would be possible. It would be a tool that checked the design according to the UI Guide: ....
That would make for a really cool 3rd party tool. As well, a source code formatting option would make for a good 3rd party tool.
After restarting my pc the arrows work. I do not know why they did not work earlier.
Thanks,
Gian
Yup, arrows work fine on my end as well. Glad someone asked this...I'd been typing in values to align/nudge. :oops: I too noticed the values jumping though to the next value that didn't seem to be in sync with the grid. Like I have mine on 4x4 and the values jump by like 15 and typing in the values just rounds them up or down 15. Been a while since I've played with Twips, but aren't they like a 3 to 1 ratio or something to pixels, so it is moving 5 per nudge or something. I'm probably wrong, but it wouldn't be the first time.
Moving by grid or 1 sounds great to me as well.
P.S.
What are these?
'[FireFly-Insert-Position]5195160
'[FireFly-Insert-Position]5195160
'[FireFly-Insert-Position]2017114
Are they markers so when the file is read in Firefly knows where to put code or what? Just wondering cause when I went to my code window last night a couple appeared there and I noticed they were in a few inc files...didn't know if they were supposed to appear like that or not.
Hi Roger,
Those "Insert position" markers should not remain in your code. Basically, they are inserted when switching between Procedure View and Full Module View. FireFly uses them to update the code that gets placed in the Procedure View window. If you can reproduce a sequence of steps that makes them appear then please let me know. I would be VERY interested in fixing it.
Twips is based on screen resolution so it is not necessarily 3:1. You can also design using pixels. Later, you can then switch back to pixels if your final program requeires some degree of screen resolution independence.
You can manually delete those "Insert position" comments.
Can't really duplicate the steps. When I open my project now and go to main form's code view they are there when selecting Full Mode. If I switch to another control and back and/or another control and switch modes then go back sometimes they go away and sometimes it just removes about half of them. I could email the project, but I don't think it would help you see how they got there in the first place. Whenever I work on another project I'll pay closer attention. Does FireFly save the project when a Compile and Run is selected? Sometimes I do a Compile/Run without saving the project first...might be something not taking out the marker comments.
There is a lot of processing that takes place when you are working in Procedure mode. Basically, for every keystroke, the buffer contents of the window are saved back into the main buffer (this is why those markers are there, to show FireFly where to do the save). There could be many reasons why the marker does not get removed. I will continue to test different scenarios.
Suffice it to say, working in Module View is much better internally to FireFly. It would have been great if the CodeMax editing control allowed me to simply turn the visibility of lines on and off. That would have made the coding of these two view modes much easier and less painful on the computer. Maybe someday if I switch to Borje's EDM32 then I'll custom code that capability into it.
QuoteDoes FireFly save the project when a Compile and Run is selected?
Yes, it must.