[a112] from [a109] conversion issue

Report problems with documented functionality
sirksel
Posts: 222
Joined: 12 Nov 2013, 23:48

[a112] from [a109] conversion issue

22 Jun 2020, 07:49

I keep getting an error with the following line, which doesn't really depend on anything. It worked in 109 but not 112. I can figure out the change that's affecting it. xl is a super-global and this appears in a function that refreshes that super-global.

Code: Select all

try return comobjtype(xl, 'iid') == 'Excel' ? xl : xl := comobjactive('excel.application')
The error I get is: "Error: Not allowed as an output variable. // Specifically: xl"
Any ideas? Is there something about the construction of this line that's no longer allowed?
Last edited by BoBo on 22 Jun 2020, 08:47, edited 1 time in total.
Reason: Moved to Bug Reports.
Helgef
Posts: 4709
Joined: 17 Jul 2016, 01:02
Contact:

Re: [a112] from [a109] conversion issue

22 Jun 2020, 12:47

I keep getting an error with the following line, which doesn't really depend on anything
I took this statement as fact and asked this to be moved to bug reports, perhaps that was premature because it seems it does depend on something, as I cannot reproduce the error you describe.

Cheers.
toralf
Posts: 868
Joined: 27 Apr 2014, 21:08
Location: Germany

Re: [a112] from [a109] conversion issue

22 Jun 2020, 13:02

Why do you return a super global var?
ciao
toralf
sirksel
Posts: 222
Joined: 12 Nov 2013, 23:48

Re: [a112] from [a109] conversion issue

22 Jun 2020, 14:49

@Helgef I've figured out why, I think, the error exists. The function is also named xl(). If I change the variable name to any other super-global name, it works. I thought this always worked before because the function namespace was separate. I referred to xl to get to the super-global object referencing the Excel instance. I referred to xl() (a top-level function) if it first needed to be refreshed. Did these namespaces get merged in the last few updates leading to a112?

@toralf The penultimate sentence above is the answer to your question. It is unusual, I know. Giving xl() a return value just allowed for quick method chaining, thereby shortening the syntax for some macros. For example: xl.selection if no comobject refresh was required, but xl().selection if a current Excel instance needed to be refreshed and/or verified. If an Excel object didn't exist or generated an error, the error was also handled in xl(), by displaying a msgbox and exiting the thread OR silently terminating (depending on user pref). There is a ton of Excel automation in this particular library.
swagfag
Posts: 6222
Joined: 11 Jan 2017, 17:59

Re: [a112] from [a109] conversion issue

22 Jun 2020, 15:26

i dont see a problem with the line either. for example

Code: Select all

global xl := 0
SetTimer(() => ToolTip(IsObject(xl)), 10)

q::
xl(*) {
	try return comobjtype(xl, 'iid') == 'Excel' ? xl : xl := comobjactive('excel.application')
}

w::xl := ''
i cant fetch/erase the instance as many times as i want, as fast as i want(fetching permits)
Did these namespaces get merged in the last few updates leading to a112?
no. classnames were turned into constants. bugs might have been introduced but we cant know that since u still havent shown the code that doesnt work. so please do, we can leave the baseless speculations for some other time
lexikos
Posts: 9583
Joined: 30 Sep 2013, 04:07
Contact:

Re: [a112] from [a109] conversion issue

24 Jun 2020, 04:05

Does ListVars show xl? Constants (currently just classes) are omitted from ListVars.
sirksel wrote: The function is also named xl(). If I change the variable name to any other super-global name, it works.
Change the function name but not the variable name. I am sure you will still get the error, because it has nothing to do with the function. There is almost definitely a class named xl, and renaming your variable avoids the conflict with that class.

The error message is the standard one that is (and has always been?) shown when you try to assign to a variable which is read-only. In the current alpha, if there is any bug causing this message, it would have to be due to corruption of internal structures, or perhaps a variable reference having been marked as the target of an assignment when it is not.

I don't think there's currently anything stopping you from declaring a super-global xl and a class xl, but perhaps there should be.
swagfag
Posts: 6222
Joined: 11 Jan 2017, 17:59

Re: [a112] from [a109] conversion issue

24 Jun 2020, 04:10

there already used to be a post after mine confirming the existence of the class xl. what happened to it? did u delete it @sirksel? did the mods?
sirksel
Posts: 222
Joined: 12 Nov 2013, 23:48

Re: [a112] from [a109] conversion issue

24 Jun 2020, 04:19

@lexikos and @swagfag Sorry friends... I pulled my post down (since it was the last) to try to make it shorter, but I didn't realize you were answering at the same time. The original post is below. You are correct, lexikos. It was a test class.

===============================

SOLVED. I wasn't trying to create baseless speculation -- sorry if that wasted your time. The entirety of the function is just about what I gave you, minus a dependent library function that never executes. Here's the xl function in full:

Code: Select all

xl() {   ;refresh global excel comobject
  try return comobjtype(xl, 'iid') == 'Excel' ? xl : xl := comobjactive('excel.application')  ;code fails at first pass HERE
  ;xmb('Excel application not running.')    ;This functions exits thread with msgbox, but it's failing before it gets here.
}
I can paste this code into its own script and it works fine, so it's true that it's failing only in context. That's why I asked my question about namespaces. In context, it fails before it's ever called (first pass?). The script is 8000 lines of proprietary client code I can't paste here. It runs fine in a109. Here's the full error dialog (minus the OK button and title bar):

Code: Select all

Error:  Not allowed as an output variable.
Specifically: xl
	Line#
	1960: }
	1963: {
	1964: (msg != '') ? mbx(msg) :0
	1965: exit(cod)
	1966: }
	1968: {
	1969: Try
--->	1969: Return comobjtype(xl, 'iid') == 'Excel' ? xl : xl := comobjactive('excel.application')
	1970: msgbox('Excel application not running.')
	1971: exit()
	1973: }
	1975: {
	1977: {
	1977: Return send('^1<100>^{tab}a!h{esc}')
	1977: }
The program will exit.
Based on your answer about "classnames turned into constants", I've found the problem. So thank you for that. There was indeed an error, but the dialog didn't help me find it too well. There was an unused test class in the code with the name xl that in a109 must have been silently overwritten.

If I change your test code just slightly to the following:

Code: Select all

global xl := 0
class xl{
}
xl(*) {
	try return comobjtype(xl, 'iid') == 'Excel' ? xl : xl := comobjactive('excel.application')
}
msgbox('done')
You can replicate the same error:

Code: Select all

Error:  Not allowed as an output variable.
Specifically: xl
	Line#
	001: xl := 0
	002: {
	000: }
	004: {
	005: Try
--->	005: Return comobjtype(xl, 'iid') == 'Excel' ? xl : xl := comobjactive('excel.application')
	006: }
	007: msgbox('done')
	008: Exit
The program will exit.
Maybe there's an opportunity for a better error message? Something about "attempting to overwrite a constant"? Maybe the error should trip when the class overwrites a super-global or when the global overwrites the class? (I can't remember if the class parse happens before super-globals.) Anyhow, I think you get the picture.

Thanks again for the help. My apologies for not isolating better in the first post.

Return to “Bug Reports”

Who is online

Users browsing this forum: No registered users and 23 guests