Hello
A few bugs :
1- Restrictions are created when using the grid or Margins to move the controls to the edges of the window.For example, when using the grid I cannot transfer control to (0,0) position.
2- I need to close the software and open it again to apply the Preferences settings.
3-Margins do not appear at all.
Version 0.0.94 bugs
-
- Registered User
- Posts: 61
- Joined: Fri Feb 02, 2018 7:44 am
Version 0.0.94 bugs
English is not my native language.
That you for reporting these
They will be fixed in next version
They will be fixed in next version
-
- Registered User
- Posts: 61
- Joined: Fri Feb 02, 2018 7:44 am
Thanks.
A suggestion:
if using snap to grid and when we dragging a control on the window,The control position must be matches with the grid when creating. It is incorrect to match the position of the control and grid when moving the controls.
A suggestion:
if using snap to grid and when we dragging a control on the window,The control position must be matches with the grid when creating. It is incorrect to match the position of the control and grid when moving the controls.
English is not my native language.
Can you elaborate please ?wilbert2940 wrote: ↑Sun Aug 25, 2019 8:41 pm if using snap to grid and when we dragging a control on the window,The control position must be matches with the grid when creating. It is incorrect to match the position of the control and grid when moving the controls.
-
- Registered User
- Posts: 61
- Joined: Fri Feb 02, 2018 7:44 am
This GIF describes everything I want to say.
According to the above GIF :
When I use Grid and drag a control on the form I can put it anywhere.In my opinion this is incorrect.I think the control and Grid must be matched when drop , not when moving controls.
Do you understand what I mean?
English is not my native language.
1. When reducing the size of the form with the mouse in the editor, it does not change after the cursor (only when you release the mouse button).
2. When you add an Edith object, you need its default height to be 21, because so the cursor sticks to the upper border and it is ugly.
3. It would not hurt to show errors at the compilation stage.
2. When you add an Edith object, you need its default height to be 21, because so the cursor sticks to the upper border and it is ugly.
3. It would not hurt to show errors at the compilation stage.
I could not see the image you mentioned ,but i think that you mean align object to closed grid corner when droppedwilbert2940 wrote: ↑Thu Sep 19, 2019 5:07 pm
This GIF describes everything I want to say.
According to the above GIF :
When I use Grid and drag a control on the form I can put it anywhere.In my opinion this is incorrect.I think the control and Grid must be matched when drop , not when moving controls.
Do you understand what I mean?
Current implementation was by design ,when designing an application first priority is performance ,resource efficiency.
Even if SDStudio uses way lower memory and CPU when compared to opponents, Functionality is also important
And it is changed as you described.
There is no default for the controls specifically designed to display text , the cursor height defined by the font you used and the font size
Therefore 21 might be looking good on your PC but 26 looking good on my PC , DPI settings affects this as well.
For this we look at the what oparating system uses with default GUI font
There will be a feature to define default size and other default properties for the controls. so you can define any width or height for a control as default.
You are probably using a display with %100 DPI ,that edit control with 21px height will appear as a line in a Hight DPI display
Even if SDStudio applications are DPI aware GUI controls must have some space especially those which display text.
Look at the images below they are taken with different DPI and font scaling That's why same size ( 26 ) is used in SDStudio IDE dialogs and 26 is not selected as default randomly
As you know Lua is a JIT language , so even if it can be pre-compiled errors will not appear until that code executed.
For example you have a logic error in the click event script of a button , that error will not appear until that button clicked.
Of cource we can simulate this but this might hurt the computer this application is running.
There is a syntax checker but that's disabled because of the false-positives , it will be enabled again when its bugs fixed
This will also be optional such as : syntax check on design time ,syntax check on build time , syntax checking disabled.
Also when you preview a project and if there is an error it will appear on the debug pane , and double clicking to error message will bring you to the exact source and line , so you can reach to erroneous code with a signle mouse click
Due to line-numbering issues of the Lua erroneous line might be +1 or -1
Still working on it to make it much better
-
- Registered User
- Posts: 61
- Joined: Fri Feb 02, 2018 7:44 am
Control alignment options have been added ,It will be available with the next version