Sign in to follow this  
Followers 0
dooshorama

A3Lib port to UDF

20 posts in this topic

i'm not involved in the forum on a regular basis, especially on the development side, so i apologize in advance if the topic has been covered.

i upgraded to 3.2.10.0 and found a large number of Const declaration errors involved with A3Lib. after using the search function on the forum, i found that Gary has ported many A3Lib functions over to UDFs. granted, it's a great effort, but i believe the project should have remained in the beta release until 100% complete and tested. all these collisions and the manual fixes involved on the user end seem unacceptable to me.

is there a concept of project-management (or manager) here or do people just check in code without approval?

i've downgraded to 3.2.8.1 in the meantime.

Share this post


Link to post
Share on other sites



The library provided by PaulIA was never an official part of AutoIt. We are under no obligation to maintain a sense of compatibility with a library we do not support. So take your bitching elsewhere as it's not warranted here.

Share this post


Link to post
Share on other sites

let's not make me into the bad guy. if your reasoning is that importing a limited set of an unsupported library into a stable release which breaks many existing "unsupported" scripts is OK, then i say your reasoning is immature and shows little understanding of an efficient project management.

the choices are 2:

1) import a fraction of the library at a time into stable release

2) import functions into beta release until 100% complete, then bring into stable release

go ahead and convince me why #1 is a better choice than #2, aside from being stubborn; i could be wrong here.

Share this post


Link to post
Share on other sites

Quite frankly, you are the "bad guy" here. You're bitching because some code we did not provide you stopped working when we started providing our own version. Think about this for a minute, you're bitching at us for expanding the language because our expansion happens to conflict with code we have no control over. If you can't accept that, it's your problem, deal with it without bitching on our forum about it.

I'll also mention that I'm not going to attempt to convince you of either point. As far as I'm concerned you're just a whiny bitch and I don't care to get into specifics about this any further. You're the one who's acting immature coming onto the forum carrying on because code we never claimed to support is suddenly incompatible with official libraries.

Lastly, remember, this is our show, if you don't like what's on, tune in elsewhere.

Share this post


Link to post
Share on other sites

let's not make me into the bad guy. if your reasoning is that importing a limited set of an unsupported library into a stable release which breaks many existing "unsupported" scripts is OK, then i say your reasoning is immature and shows little understanding of an efficient project management.

the choices are 2:

1) import a fraction of the library at a time into stable release

2) import functions into beta release until 100% complete, then bring into stable release

go ahead and convince me why #1 is a better choice than #2, aside from being stubborn; i could be wrong here.

#2 is reality - look into AutoIt beta changelog!!

There is not problem withAutoIt - it's not buggy

but problem is in Auto3Library - it's incompatible with new version of AutoIt 3.2.10

and unfortunatelly Auto3Library developpment/maintaining was stopped long time ago.

In AutoIt 3.2.10 is ported all Auto3Library functionality but in changed syntax (standard AutoIt UDF compatible syntax).

So problem is only on users side:

If you have scripts using A3L includes (Auto3Library) you must:

- compile such scripts only with AutoIt 3.2.8.1

or

- fix (comment) constants declarations in all A3L include files by hand yourself

or

- rewrite your scripts to use new UDF include files/functions from AutoIt 3.2.10

I have many scripts with A3L includes and I have no time to rewrite/test them all just now

so I'm staying at AutoIt 3.2.8.1 too. But I don't complain about that problem as you.

When I will have more time I will upgrade to 3.2.10 and I will rewrite my scripts.

Share this post


Link to post
Share on other sites

let's not make me into the bad guy. if your reasoning is that importing a limited set of an unsupported library into a stable release which breaks many existing "unsupported" scripts is OK, then i say your reasoning is immature and shows little understanding of an efficient project management.

the choices are 2:

1) import a fraction of the library at a time into stable release

2) import functions into beta release until 100% complete, then bring into stable release

go ahead and convince me why #1 is a better choice than #2, aside from being stubborn; i could be wrong here.

If you had kept up with the beta and release versions you would know that the functions were introduced into the beta, then the release.


SciTE for AutoItDirections for Submitting Standard UDFs

 

Don't argue with an idiot; people watching may not be able to tell the difference.

 

Share this post


Link to post
Share on other sites

ah, i see. :)

thank you zedna and gary for the clarification. from reading the general help forum, i gathered that the port was only partially done for 3.2.10.0. now i've been corrected. :)

sorry valik; you seem to have personal issues i'd rather not get involved with - take it easy.

well then, ^_^

Share this post


Link to post
Share on other sites

sorry valik; you seem to have personal issues i'd rather not get involved with - take it easy.

If you had even 1/100th of the psycho-analytical prowess necessary to make any form of analysis of me, you'd be making a mint in that field, not fooling about on a scripting forum.

Share this post


Link to post
Share on other sites

#9 ·  Posted (edited)

Hi,

is there already a list for A3lib _TreeView_.. to UDF _GUICTRLTreeView_.. available.

Assuming that sometimes A3lib going over into standard I avoid A3lib, but _Treeview_ saved much time.

I looked already for it and think mostly can be translated directly, but there are also to consider some special, item instead of node, _TreeView_Parent I didn't find, ...

If someone already has a list, like the attached list from Gary for transfering _GuiCtrListView to the new _GuiCtrListView_ (or already a script for it) it would be fine to get it.

Best regards, Reinhard

PS: I attached the list from Gary because I searched here for it.

; #OLD_FUNCTIONS#=====================================================================================



===========================
; Old Function/Name                 ; --> New Function/Name/Replacement(s)
; ====================================================================================================



===========================
;_GUICtrlListViewCopyItems            ; --> _GUICtrlListView_CopyItems
;_GUICtrlListViewDeleteAllItems      ; --> _GUICtrlListView_DeleteAllItems
;_GUICtrlListViewDeleteColumn       ; --> _GUICtrlListView_DeleteColumn
;_GUICtrlListViewDeleteItem          ; --> _GUICtrlListView_DeleteItem
;_GUICtrlListViewDeleteItemsSelected    ; --> _GUICtrlListView_DeleteItemsSelected
;_GUICtrlListViewEnsureVisible        ; --> _GUICtrlListView_EnsureVisible
;_GUICtrlListViewFindItem           ; --> _GUICtrlListView_FindInText, _GUICtrlListView_FindItem,   _GUICtrlListView_FindNearest, _GUICtrlListView_FindParam, _GUICtrlListView_FindText
;_GUICtrlListViewGetBackColor       ; --> _GUICtrlListView_GetBkColor
;_GUICtrlListViewGetCallbackMask        ; --> _GUICtrlListView_GetCallbackMask
;_GUICtrlListViewGetCheckedState        ; --> _GUICtrlListView_GetItemChecked
;_GUICtrlListViewGetColumnOrder      ; --> _GUICtrlListView_GetColumnOrder
;_GUICtrlListViewGetColumnWidth      ; --> _GUICtrlListView_GetColumnWidth
;_GUICtrlListViewGetCounterPage      ; --> _GUICtrlListView_GetCounterPage
;_GUICtrlListViewGetCurSel            ; --> _GUICtrlListView_GetNextItem
;_GUICtrlListViewGetExtendedListViewStyle; --> _GUICtrlListView_GetExtendedListViewStyle
;_GUICtrlListViewGetHeader            ; --> _GUICtrlListView_GetHeader
;_GUICtrlListViewGetHotCursor       ; --> _GUICtrlListView_GetHotCursor
;_GUICtrlListViewGetHotItem          ; --> _GUICtrlListView_GetHotItem
;_GUICtrlListViewGetHoverTime       ; --> _GUICtrlListView_GetHoverTime
;_GUICtrlListViewGetItemCount       ; --> _GUICtrlListView_GetItemCount
;_GUICtrlListViewGetItemTextArray   ; --> _GUICtrlListView_GetItemTextArray
;_GUICtrlListViewGetItemText            ; --> _GUICtrlListView_GetItemTextString
;_GUICtrlListViewGetNextItem            ; --> _GUICtrlListView_GetNextItem
;_GUICtrlListViewGetSelectedCount   ; --> _GUICtrlListView_GetSelectedCount
;_GUICtrlListViewGetSelectedIndices  ; --> _GUICtrlListView_GetSelectedIndices
;_GUICtrlListViewGetSubItemsCount   ; --> _GUICtrlListView_GetColumnCount
;_GUICtrlListViewGetTopIndex            ; --> _GUICtrlListView_GetTopIndex
;_GUICtrlListViewGetUnicodeFormat   ; --> _GUICtrlListView_GetUnicodeFormat
;_GUICtrlListViewGetView                ; --> _GUICtrlListView_GetView
;_GUICtrlListViewHideColumn          ; --> _GUICtrlListView_HideColumn
;_GUICtrlListViewInsertColumn       ; --> _GUICtrlListView_InsertColumn
;_GUICtrlListViewInsertItem          ; --> _GUICtrlListView_InsertItem
;_GUICtrlListViewJustifyColumn        ; --> _GUICtrlListView_JustifyColumn
;_GUICtrlListViewScroll              ; --> _GUICtrlListView_Scroll
;_GUICtrlListViewSetColumnHeaderText    ; --> _GUICtrlListView_SetColumn
;_GUICtrlListViewSetColumnWidth      ; --> _GUICtrlListView_SetColumnWidth
;_GUICtrlListViewSetColumnOrder      ; --> _GUICtrlListView_SetColumnOrder
;_GUICtrlListViewSetCheckState        ; --> _GUICtrlListView_SetItemChecked
;_GUICtrlListViewSetHotItem          ; --> _GUICtrlListView_SetHotItem
;_GUICtrlListViewSetHoverTime       ; --> _GUICtrlListView_SetHoverTime
;_GUICtrlListViewSetItemCount       ; --> _GUICtrlListView_SetItemCount
;_GUICtrlListViewSetItemSelState        ; --> _GUICtrlListView_SetItemSelected
;_GUICtrlListViewSetItemText            ; --> _GUICtrlListView_SetItemText
;_GUICtrlListViewSort               ; --> _GUICtrlListView_SimpleSort
Edited by ReFran

Share this post


Link to post
Share on other sites

Hi,

is there already a list for A3lib _TreeView_.. to UDF _GUICTRLTreeView_.. available.

Assuming that sometimes A3lib going over into standard I avoid A3lib, but _Treeview_ saved much time.

I looked already for it and think mostly can be translated directly, but there are also to consider some special, item instead of node, _TreeView_Parent I didn't find, ...

If someone already has a list, like the attached list from Gary for transfering _GuiCtrListView to the new _GuiCtrListView_ (or already a script for it) it would be fine to get it.

Best regards, Reinhard

No there isn't and I don't plan creating a list either.

Took long enough as it was to port/merge the code.


SciTE for AutoItDirections for Submitting Standard UDFs

 

Don't argue with an idiot; people watching may not be able to tell the difference.

 

Share this post


Link to post
Share on other sites

No there isn't and I don't plan creating a list either.

Took long enough as it was to port/merge the code.

OK. No problem.

Wanted only to avoid extra work.

Didn't wanted to distribute extra work.

However will write a short script for the parts I need.

The first quick manual translation didn't work very well.

Thanks for your work on the integration.

Bet regards, Reinhard

Share this post


Link to post
Share on other sites

Hoping this is the right place, but having a little problem: the new _guictrllistview_deleteallitems() pops a messagebox with an error if you use it on a listview containing controls created with autoit (the messagebox says "Use GUICtrlDelete to delete items or if items were created with UDF functions MAKE sure to pass in handle to control NOT the controlid").

The old _guictrllistviewdeleteallitems() worked on either. Any way this can be fixed to function the same work?

Share this post


Link to post
Share on other sites

from the error message, i would assume you are passing the controlID, not the handle -- did you read it?

use ControlGetHandle.

Share this post


Link to post
Share on other sites

from the error message, i would assume you are passing the controlID, not the handle -- did you read it?

use ControlGetHandle.

I think it is pretty clear that I read it, since I quoted it verbatim...

I'm trying to delete all of the treeview and listview items out of controls created in an autoit GUI. ControlGetHandle does not fix this that I can see.

Share this post


Link to post
Share on other sites

Given that somebody explicitly added a message to the code to tell you about this, did you think that maybe it's not going to change?

from the error message, i would assume you are passing the controlID, not the handle -- did you read it?

use ControlGetHandle.

Did you really think about this? The error message clearly states, if it's a native GUI control, use GUICtrlDelete() on it. What you suggest could very well cause AutoIt to crash when AutoIt thinks a control is still there but it's been destroyed elsewhere.

Don't mix control creation/destruction. If you made it using native functions, destroy it using GUICtrlDelete(). If you made it using a UDF, destroy it with the appropriate UDF.

Share this post


Link to post
Share on other sites

Did you really think about this?

i've clearly demonstrated my first instinct is to say something stupid then think when smarter people point things out to me.

so, no.

anywho, maybe we can close this thread. :)

Share this post


Link to post
Share on other sites

#17 ·  Posted (edited)

Given that somebody explicitly added a message to the code to tell you about this, did you think that maybe it's not going to change?

I wasn't aware that any time someone added a message to the code, that meant that it was a permanent decision that was not open to any input or debate. If that isn't the case, then I take exception to your question.

Did you really think about this? The error message clearly states, if it's a native GUI control, use GUICtrlDelete() on it. What you suggest could very well cause AutoIt to crash when AutoIt thinks a control is still there but it's been destroyed elsewhere.

Don't mix control creation/destruction. If you made it using native functions, destroy it using GUICtrlDelete(). If you made it using a UDF, destroy it with the appropriate UDF.

Was this actually a problem? I have been _guictrltreeviewdeleteall() - ing giant tree views for some time now and never got a crash that I attribute to that behavior. I do mean this honestly- is there some cause for worry over this or are we simply speculating?

Lastly, are you speaking in an official capacity that the behavior is not going to change? I only ask so I know whether I should start re-engineering the way my code works. If it is a permanent change, I hope that the idea of popping a modal text box in what amounts to a programming error is open for re-evaluation.

It would be nice if this update were clearly marked somewhere as breaking all the previous guictrlcombo, guictrllistview, guictrltreeview UDF functionality which has shipped with autoit for some time. It would be one thing if it were merely syntax changes, but we've got some actual behavior changes here.

Edited by Hostage

Share this post


Link to post
Share on other sites

#18 ·  Posted (edited)

I wasn't aware that any time someone added a message to the code, that meant that it was a permanent decision that was not open to any input or debate. If that isn't the case, then I take exception to your question.

Anytime anybody adds something to the code, they have a reason. Give them the benefit of the doubt that they know what they are doing.

Was this actually a problem? I have been _guictrltreeviewdeleteall() - ing giant tree views for some time now and never got a crash that I attribute to that behavior. I do mean this honestly- is there some cause for worry over this or are we simply speculating?

I'm not sure what the specific reason is. However, my opinion is, you should not be doing it. As I said earlier, if you create it with one set of functions, destroy it with the matching set.

Lastly, are you speaking in an official capacity that the behavior is not going to change? I only ask so I know whether I should start re-engineering the way my code works.

The behavior was changed for a reason. I trust that the reason is good and I'm not concerned about it.

If it is a permanent change, I hope that the idea of popping a modal text box in what amounts to a programming error is open for re-evaluation.

The message will not last forever, however, there's not really any other way to jump up and tell the scripter the behavior has changed.

It would be nice if this update were clearly marked somewhere as breaking all the previous guictrlcombo, guictrllistview, guictrltreeview UDF functionality which has shipped with autoit for some time. It would be one thing if it were merely syntax changes, but we've got some actual behavior changes here.

You know what else would be nice? Users who weren't naive and assumed things with syntactical changes were no more than just that. If something changes, treat it as a new thing until you've confirmed yourself that it's the same wall, just with a new coat of paint. Oh, and it is documented. See the "UDF History" section in the help file. You're looking for:

Fixed: _GUICtrlListView_DeleteAllItems deleting listiview, handle now required (GaryFrost)

Edited by Valik
Typo (removed).

Share this post


Link to post
Share on other sites

You know Valik, I had a line by line response to you but I've erased it in an attempt to thwart your needlessly aggressive and adversarial responses. I am no longer interested in your unhelpful speculative replies so I would appreciate it if you would refrain from providing them.

The treeview delete all function still happily deletes both native and udf controls. It is only the listview delete all function which pops the message. Here is the code:

Func _GUICtrlListView_DeleteAllItems($hWnd)

If $Debug_LV Then _GUICtrlListView_ValidateClassName($hWnd)

If _GUICtrlListView_GetItemCount($hWnd) == 0 Then Return True

;~ Local $iIndex, $control_ID

If IsHWnd($hWnd) Then

Return _SendMessage($hWnd, $LVM_DELETEALLITEMS) <> 0

Else

_WinAPI_ShowError("Use GUICtrlDelete to delete items" & @CRLF & "Or if items were created with UDF functions MAKE sure to pass in handle to control NOT the controlid", False)

;~ For $iIndex = _GUICtrlListView_GetItemCount($hWnd) - 1 To 0 Step - 1

;~ _GUICtrlListView_SetItemSelected($hWnd, $iIndex, True)

;~ $control_ID = GUICtrlRead($hWnd)

;~ If $control_ID Then GUICtrlDelete($control_ID)

;~ Next

;~ If _GUICtrlListView_GetItemCount($hWnd) == 0 Then

;~ Return True

;~ Else

;~ Return GUICtrlSendMsg($hWnd, $LVM_DELETEALLITEMS, 0, 0) <> 0

;~ EndIf

EndIf

EndFunc

If one removes the read-only flag from the include file, uncomments those lines and comments out the message it works fine. Very clearly the original functionality was, at a minimum, considered. As much as I hate to mess with the includes files, this solves my problem for now until I can rewrite to take advantage of the obviously better UDF.

I am a little reluctant though to go down that road- we've already seen a complete deprecation of the previous UDF for this- does anybody know how stable the new one will be as far as introducing changes in functionality? Further, I have to be able to change the text color of the individual treeview items and I haven't found a way to do that with the UDF controls.

I still assert it would be helpful to warn people before they download and install the new version of serious changes in UDFs which ship with the product. As Valik points out, the help file (once it is installed!) alerts you to that but that really isn't necessary- it becomes obvious when you first try to run an old script.

Just to be clear, I do appreciate the enhanced functionality of the UDF. All I'm asking for is a little backwards compatibility.

Share this post


Link to post
Share on other sites

You know Valik, I had a line by line response to you but I've erased it in an attempt to thwart your needlessly aggressive and adversarial responses. I am no longer interested in your unhelpful speculative replies so I would appreciate it if you would refrain from providing them.

Fine, then you'll get no further help on this subject publicly on the forum.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this  
Followers 0