117 replies to this topic

[lookfar]

No, I am just using an XP theme, which only chanes colors, icons and so on. I really do not think that this is the problem. I disabled the theme (went back to Windows Classic) and I still have the same problem (see the attached picture)

try new build just uploaded.

Do you mean that it will work with other languages other than AutoIt as well? Because AutoIt is a windows only app, right?

Your kidding right?

Also, instead of looking if AutoIt is installed, can't you intead check if the 'AU3' files are assigned to AutoIt3.exe? When you install autoit it creates several "actions" associated to the AU3 files. One is Run Script, another Edit Script another Compile Script and so on. Perhaps there is a way to do call those particular accions on the au3 file without reading the registry... Then you could also add a "Compile button" and so on.
Yeah, that is why it'd be so much more handy to be able to open the assigned editor instead. Same thing for a compiler button.

Nope not reading the registry...

A last suggestion would be that it could be interesting to automatically add in the beginning of the file, as a comment, the autoit3 version for which the file was made (3.1.0, or 3.1.1 and so on). That'd be handy whenever something changes in the AutoIt3 specification.

what part of...oh forget it.
not reading the registry...
you can however goto options and insert whatever information you like in the header.

Edited by lookfar, 04 November 2005 - 11:58 PM.

[Angel]

try new build just uploaded.

I still have the same problem
I tried it in another Windows XP PC and there was the same problem there as well. By the way I was showing it to a colleage and he was blown away as well !

Your kidding right?

Kind of ... When you say that you want the tool to be portable, is it because you want to be able to create AutoIt forms in Linux, for instance, or is it because you want to be able to use FormDesigner for other languages other than AutoIt? I'd just like to understand what you meant and the reason why you do not want to read from the registry. I really am not trying to bother you with this question.

you can however goto options and insert whatever information you like in the header.

You do not need to read the registry or even know where AutoIt.exe is to be able to put the information about the target AutoIt version in the header! You already know for what AutoIt version you are automatically generating the code. If, let's say, in version 3.1.2 they changed the syntax of GuiCreate, you would need to change FormDesigner to take into account that change, right? So you would now for what version of AutoIt your code was meant, and thus you already have the information that you could put in the header.

It is not a big deal, I just think that it might be handy.

Cheers,

Angel

[lookfar]

I still have the same problem

uploaded new build again..
Is anyone else having this screen problem?

When you say that you want the tool to be portable, is it because you want to be able to create AutoIt forms in Linux, for instance, or is it because you want to be able to use FormDesigner for other languages other than AutoIt? I'd just like to understand what you meant and the reason why you do not want to read from the registry. I really am not trying to bother you with this question.

Koda does not use any external dll's or librarys or is dependent on any system files, this means you can run it from a floppy drive or add it to your tools cd and use it where ever you happen to be without the need to install it, it will run on any 32bit os. I dislike the registry and prefer to use ini or xml for all app config.
my preferred OS is Linux but I'm running Windows right now because I'm developing this application for the windows platform. I have no intention of porting this to linux as there is not too much point in that...
Koda was developed for AutoIt, there are lot's of GUI IDE's for other languages but not much for AutoIt that is why we wrote it.
btw: just for fun I did run Koda as is, in Linux (under Wine) but really not much point in it.

Edited by lookfar, 05 November 2005 - 06:41 AM.

[Angel]

uploaded new build again..
Is anyone else having this screen problem?

I'll try it tomorrow at work and let you know if it works. I tried it in my home PC and it did. Thanks!

Koda does not use any external dll's or librarys or is dependent on any system files, this means you can run it from a floppy drive or add it to your tools cd and use it where ever you happen to be without the need to install it, it will run on any 32bit os. I dislike the registry and prefer to use ini or xml for all app config.
my preferred OS is Linux but I'm running Windows right now because I'm developing this application for the windows platform. I have no intention of porting this to linux as there is not too much point in that...
Koda was developed for AutoIt, there are lot's of GUI IDE's for other languages but not much for AutoIt that is why we wrote it.

OK, so then I do not get why you do not like reading the register. I understand why you do not want to _write_ to the registry. That allows you to run KODA from a USB stick for instance, but the registry is where a lot of the configuration for Windows and many other programs is. Reading it does not make you program (IMHO) less portable. There is a lot of cool functionality that you could easily implement by reading from the registry (like the program used to "run" au3 files and the one used to "Edit" them. So I hope you reconsider whether it migh be a good idea to _read_ from (but not write to) the registry.

Anyway, I am looking forward to what else you offer to us when you update this fantastic program. I trully want you to know that this is awesome already as it is.

Cheers,

Angel

[Angel]

uploaded new build again..
Is anyone else having this screen problem?

I just tried it again on my work PC. It is better not fixed yet.
The problem only happens if I am not using the Windows Classic theme. If I use the WindowsXP theme (not a custom theme, but the one that is used by default by WindowsXP) the main window is still slightly too small and makes the icons in the toolbar be partially hidden (but not enough to net make them usable).

As I said this only happens when I do not have the Windows Classic theme. But with the default Windows XP theme there is a little problem.

I attach 3 pictures. The first one is how it looks with the WindowsXP theme. The second how it looks when I change to the Windows Classic theme (but Koda was already open before the change). The last one shows how Koda looks if I open _after_ I've changed to the Windows Classic theme. In this last case there is no problem anymore.

So it seems that the window size is not properly calculated when not using the Classic theme.

Cheers,

Angel

[lookfar]

So it seems that the window size is not properly calculated when not using the Classic theme.

Cheers,

Angel

Ok that helps tremendously. I have done a re-work on the form and how it is scaled as well as a few other improvements. Just a few things to work out with the new features, but the above situations have been addressed. (not uploaded yet)
again, thanks for the input and we are gratified that you are finding the program useful.

[ptrex]

@lookfar

Hello I think you dd a great job making KODA for all the AutoIT members !!

I used it quite a whlle.

I saw that all the data is stored into an XML file.
My question is the following. Someone else created a Form Designer using MS Access, maybe you have seen this.

http://www.autoitscript.com/forum/index.php?showtopic=17588

It would be a huge benifit if both applications could use each others data.
MS Access can import XML files. I did a test reading your XML files of KODA. And it went OK partly.
The data structure is read OK, but not the data itself.

The reason is that the structure of the XML files of KODA or not 100 percent in line with what Access can read.

It there a possibility that both can grow together so that files can be read from KODA by MS ACCESS and visa versa.

The only thing that needs to change a bit is the structure of the KODA XML files.

Can this be done or are you forced to use this XML structure as it is now ?

[Aaron]

hello,lookfar.
it is very nice,i like it very much.
it looks like NIS Edit(a nsis script tool)'s form designer...
i used it very frequently..
so i like koda formdesigner so much~~
but there is a err at everytime i quit the koda.



ps: it is in chinese os.

[Lazycat]

It would be a huge benifit if both applications could use each others data.
MS Access can import XML files. I did a test reading your XML files of KODA. And it went OK partly.
The data structure is read OK, but not the data itself.

The reason is that the structure of the XML files of KODA or not 100 percent in line with what Access can read.

It there a possibility that both can grow together so that files can be read from KODA by MS ACCESS and visa versa.

Very little chance that this will be possible. Probably we can do in the future import of other format(s).

The only thing that needs to change a bit is the structure of the KODA XML files.

What the "bit" of changes is need to structure? Can you post example of required structure?

so i like koda formdesigner so much~~
but there is a err at everytime i quit the koda.

I'm can not represent this error... You use latest version? This was in the previous versions?

[Aaron]

I'm can not represent this error... You use latest version? This was in the previous versions?

Yes.It is the lastest version.I downloaded it today earlier.
Maybe it is caused by my chinese os.
Forget it.The err won't impact me in using.
Thank you.^^

[CatchFish]

Nice app! Since the beta version I've been using it...

So is it possible to add the system menu for a form yet? I'm so eager to that functionality.

[Lazycat]

So is it possible to add the system menu for a form yet? I'm so eager to that functionality.

No at the moment, but this is in the closest planes.

[CatchFish]

Well, a few bugs here:

• The width and height of label controls are never restored from the xml file.
• Why is "MS San Serif" always the default font? My system default is Tahoma, or SimSun. This sometimes causes label to wrap in the actual AutoIt script, due to the auto-adjust-width feature based on the wrong font.
• If there are two or more date picker controls on the same form, during loading the saved xml file it says "Error reading ADate2.Date: Invalid property value", and the form is not painted. In fact I didn't set any properties of any date picker controls, just put them on the form!
• A control could be dragged to an unexpected place when I CLICK it and quickly move the cursor to somewhere else.

(KODA FormDesigner 1.3.2.23, Windows XP SP2, AutoIt 3.1.1.87)

[Lazycat]

Thanks for feedback!

[*]The width and height of label controls are never restored from the xml file.

This is due AutoSize was enabled. Now I enabled AutoSize property in the inspector, so in the next build if you need to keep label size just set this property to false.

[*]Why is "MS San Serif" always the default font? My system default is Tahoma, or SimSun. This sometimes
causes label to wrap in the actual AutoIt script, due to the auto-adjust-width feature based on the wrong font.

Hm, you right. Default fonts and colors need to tweak.

[*]If there are two or more date picker controls on the same form, during loading the saved xml file it says "Error reading ADate2.Date: Invalid property value", and the form is not painted. In fact I didn't set any properties of any date picker controls, just put them on the form!

This bug is fixed in current snapshot.

[*]A control could be dragged to an unexpected place when I CLICK it and quickly move the cursor to somewhere else.

Can't represent this... maybe I'm not fast enough?

[ptrex]

Coming back to the XML structure, we talked about a while ago.

What the "bit" of changes is need to structure? Can you post example of required structure?

I have here 2 exaples of XML code that Access can read.

<dataroot>
<note>
<to><TextValue>Tove</TextValue></to>
<Value>Tove</Value>
</note>
<note>
<from><TextValue>Jani</TextValue></from>
<Value>Jani</Value>
</note>
<note>
<heading><TextValue>TurnoverReminder</TextValue></heading>
<Value>TurnoverReminder</Value>
</note>
<note>
<body><TextValue>Don't forget me this weekend!</TextValue></body>
<Value>Don't forget me this weekend!</Value>
</note>
</dataroot>

and

<dataroot>
<note>
<to>Tove</to>
<Value>Tove</Value>
<from>Jani</from>
<Value>Jani</Value>
<heading>TurnoverReminder</heading>
<Value>TurnoverReminder</Value>
<body>Don't forget me this weekend!</body>
<Value>Don't forget me this weekend!</Value>
</note>
</dataroot>

It does not look that much different than the the KODA output but only the tags are different.

Try opening ACCESS and import these 2 examples to see the effect.

I hope this can help to standardize the XML format.

[Gene]

@Lookfar
@Lazycat

While using Koda , I opened DualListDlg.xml from the templates folder. I resized it
and some of the contols, added a button, and moved the others around. On the 2 list
boxes I removed the sort style and added the multiple select and vertical scroll styles.

I then generated it, copied and pasted into Scite and saved it. When I ran the script it
gave the following error message:

Line 4 (File "K:\ETS Documents\_Dev\Projects\PreCompile\LeftRight.au3"):

$ListBox1 = GUICtrlCreateList("", 18, 10, 184, 230, BitOR($LBS_MULTIPLESEL,$WS_VSCROLL),
$WS_EX_CLIENTEDGE)
$ListBox1 = GUICtrlCreateList("", 18, 10, 184, 230, BitOR(^ ERROR

Error: Variable used without being declared.

The generated code is below:

Plain Text        expandcollapse  popup

#include <GUIConstants.au3>
;Generated with Form Designer preview
$Form2 = GUICreate("CompileAssist Choices Dialog", 529, 471, 288, 114)
$ListBox1 = GUICtrlCreateList("", 18, 10, 184, 230, BitOR($LBS_MULTIPLESEL,$WS_VSCROLL), $WS_EX_CLIENTEDGE)
GUICtrlSetData(-1, "#Compiler_Allow_Decompile=y|#Compiler_AUT2EXE=|#Compiler_AUTOIT3=|#Compiler_Compression=4|#Compi

ler_Icon=|#Compiler_OutFile=|#Compiler_PassPhrase=|#Compiler_Prompt=y|#Compiler_Res_Comment=Precompi

le [Compiler Ver. 3.1.1.87]|#Compiler_Res_Description=|#Compiler_Res_Field=Email: |#Compiler_Res_FileVersion_AutoIncrement=y|#Compiler_Res_Fileversion=0.0.0.00|#Compiler_Res_LegalCop

yright=|#Compiler_Run_After=RunAfter.exe "&Chr(34)&"%in%"&Chr(34)&"|#Compiler_Run_AU3Check=n|#Compiler_Run_Before=CompileAssist.exe %in%|#EndRegion|#Region Compiler directives section")
$Button1 = GUICtrlCreateButton("==>", 240, 18, 37, 31)
$Button2 = GUICtrlCreateButton("=>>", 240, 59, 38, 31)
$Button3 = GUICtrlCreateButton("<==", 241, 100, 38, 30)
GUICtrlSetState(-1, $GUI_DISABLE)
$Button4 = GUICtrlCreateButton("<<=", 241, 140, 40, 31)
$ListBox2 = GUICtrlCreateList("", 318, 10, 193, 230, BitOR($LBS_MULTIPLESEL,$WS_VSCROLL), $WS_EX_CLIENTEDGE)
$Button5 = GUICtrlCreateButton("C&ontinue", 224, 437, 92, 31)
$Button6 = GUICtrlCreateButton("&Cancel", 322, 437, 93, 31)
$Button7 = GUICtrlCreateButton("&Help", 421, 437, 92, 31)
$Label1 = GUICtrlCreateLabel("Variable or Directive Name", 16, 248, 166, 18)
$Edit1 = GUICtrlCreateEdit("", 16, 272, 497, 49, -1, $WS_EX_CLIENTEDGE)
GUICtrlSetData($Edit1, "AEdit1")
$Edit2 = GUICtrlCreateEdit("", 16, 360, 497, 65, -1, $WS_EX_CLIENTEDGE)
GUICtrlSetData($Edit2, "AEdit2")
$Label2 = GUICtrlCreateLabel("Variable or Directive Value", 16, 328, 164, 18)
$Button1 = GUICtrlCreateButton("&Save", 16, 437, 92, 31)
$Label3 = GUICtrlCreateLabel("Add ==>", 260, 178, 53, 20)
$Label4 = GUICtrlCreateLabel("<== Remove", 208, 208, 80, 20)
GUISetState(@SW_SHOW)
While 1
    $msg = GuiGetMsg()
    Select
    Case $msg = $GUI_EVENT_CLOSE
        ExitLoop

    Case $msg = "foo"


    Case Else
    ;;;;;;;
    EndSelect
WEnd
Exit

I don't see what is wrong with it. I'm using beta 87 and have toggled the beta to be the default.

Edit: Line wrap for non-code items

Edit 2: I did some poking about. I found this style ($LBS_MULTIPLESEL)
referenced in several examples on disk, but not in GUIConstants.au3. In the
examples it is specified as

Dim $LBS_MULTIPLESEL = 0x8.

When I add that DIM statement to the script it doesn't error and it does allow me
to multiselect in the list box, I guess this posting needs to be moved to the bug
list. I think the moderators have to do that.


In earlier looking I didn't find anything in the Help file when I searched for "$LBS_"
using the Help File Search TAB. When I went directly to the Styles page and and
did a [Ctrl]+[F] search for "$LBS_", I found several listings but not
"$LBS_MULTIPLESEL" I did find it in the Help File examples dealing with list box
issues that I looked at.

Edited by Gene, 13 November 2005 - 08:57 AM.

[CatchFish]

Can't represent this... maybe I'm not fast enough?

Surely this bug exists in v1.3! It could happen on a label, a button, a groupbox, or anything else. At this moment, I have to click the control and hold the mouse steadily still for a second or two when trying to select a control. (OS: XP sp2)

If you want to represent it, just put a button on a form, then try to CLICK & MOVE on that button. For details: It won't happen if you hold down the left button & release & move. Instead, give it a short click. At the very moment when the left button is up, move the cursor out of the button. This is not dragging, but the button is moved. I've done that tens of times (accidentally), and I've suffered too much from it...

Edited by CatchFish, 13 November 2005 - 09:46 AM.

[lookfar]

Surely this bug exists in v1.3! It could happen on a label, a button, a groupbox, or anything else. At this moment, I have to click the control and hold the mouse steadily still for a second or two when trying to select a control. (OS: XP sp2)

If you want to represent it, just put a button on a form, then try to CLICK & MOVE on that button. For details: It won't happen if you hold down the left button & release & move. Instead, give it a short click. At the very moment when the left button is up, move the cursor out of the button. This is not dragging, but the button is moved. I've done that tens of times (accidentally), and I've suffered too much from it...

CatchFish,
please check your mouse settings:
control panel ->Mouse ->Buttons ->ClickLock (checked/unchecked)
if checked then goto settings and drag to long, or uncheck clicklock completely
The only way I could duplicate your experience was by checking clicklock and setting clicklock to short.
on most systems clicklock is off by default.

[lookfar]

A new Koda FormDesigner (Beta) has just been uploaded. which fixes a few issues as well as a few new features have been implemented.

The latest (stable) version is available as well as a Beta preview on the Koda web page.
please note: the default file extension for Forms has been changed, although the XML structure is still the same.
Due to overwhelming demand Koda now reads from the registry certain keys and has the ability to associate the new file extension.

Have Fun!

[ptrex]

@lookfar

the default file extension for Forms has been changed, although the XML structure is still the same.

Does this mean your are not going to change to XML structure, in order to be able to read this for Access import (or any other XML compliant application) ?

Bye the way changing the extention from XML to KXF makes it now impossible to interchange your KODA forms data, with any XML compliant applications. Because they only read by default files with extentions XML.

This means you are moving away from the power of what XML has, is that correct ?