External Module dropped in a project turned yellow...

General
1

Hi !

Quick question: mac 10.9.2 / Xojo 2013r3.3
In Project A I created an external module with one (global) method in it. I saved & closed Project A.
Then I opened Project B and drag&dropped the external module into it. (by holding down Alt+Cmd)

The module appeared - as expected - with the little alias badge on it. But the color of the module was yellow :wink:
Why ? What does it mean ?
My guess is it has something to do with scope, but I don’t see any way to change the scope of the module itself


Thanks :wink:

2

You can only change the scope of a module if it is inside another Module. Was it inside a Module in projectA?

3

No.

4

I discarded the external module and created it from scratch. (I also used different names for the Module and its Method this time.)
Now it shows up as expected.

There might be an IDE bug here, but I haven’t been able to reproduce it reliably


5

Here’s 7 bugs I found in the past week
 Minor fixes, but nonetheless
but really noticable (Can put in bug reporter on Monday).

(Windows)

I have seen this also. If you save the project, close the ide and reload the project it will be normal. Another xojo custom listbox bug includes computed properties saying “mwhatever=value”, yet actually only creates a private “whatever” acaccompanying variable.

Newly created variables doesn’t highlight “untitled” on creation (cursor ends up after the final ‘d’).

Changes to the the ide design interface (listbox/combo/few others) doesn’t load unless you view code and return to the IDE designer.

Paste doesn’t appear in the IDE designer contextual menu but works by keycode or mainmenu (cut/copy exist in both and work).

If you create a menuhandler and manually type its name rather than select from the dropdown, enter code, then navigate to another part of the IDE the name reverts to “untitled” as well
 The key to the menuhandler is to use the dropdown or press enter after entering the name manually “to make it stay” (possibly should be lostfocus?).

When using the segment editor for segmentedcontrols, clicking or double clicking the initial (or added) “one” or “two” does not make it edit-able". On windows you have to right click then left click to make it edit-able. If you use images for segmentedcontrol, in the segment editor the picture names are duplicated and slightly offset from eachother.

6

Not a bug as compute properties cannot have initial values - in 2014r1.1 this actually removes the initial value for computed properties.
A backing property for it can have an initial value

[quote=83227:@Matthew Combatti]If you create a menuhandler and manually type its name rather than select from the dropdown, enter code, then navigate to another part of the IDE the name reverts to “untitled” as well
 The key to the menuhandler is to use the dropdown or press enter after entering the name manually “to make it stay” (possibly should be lostfocus?).
[/quote]
After you typed did you press return tab or enter ?

7

[quote=83234:@Norman Palardy]Not a bug as compute properties cannot have initial values - in 2014r1.1 this actually removes the initial value for computed properties.
A backing property for it can have an initial value

After you typed did you press return tab or enter ?[/quote]

I originally did not press enter (I have learned to) when I first noticed it
 but have wondered if it was a bug since changing values anywhere else in the IDE, IDE designer pencil popups, and property inspector retain their changes on “enter”, “tab”, and “lostfocus” events. This was the only place in the IDE that didn’t exhibit the same IDE-wide behavior.

8

~Auto spell failure on accompanying.

I had wondered about computed properties since half the time it generates a private “mwhatever” (still) automatically, and other times, it automatically creates the accompanying private “whatever” value, but refers to it in the set handler as “mwhatever” (which raises mwhatever value does not exist).

9

Not always - theres still spots where clicking something else doesn’t move the focus so what you typed doesn’t get committed

10

[quote=83237:@Matthew Combatti]~Auto spell failure on accompanying.

I had wondered about computed properties since half the time it generates a private “mwhatever” (still) automatically, and other times, it automatically creates the accompanying private “whatever” value, but refers to it in the set handler as “mwhatever” (which raises mwhatever value does not exist).[/quote]
Depends on if you create a new computed property (that won’t create an accompanying backing property) where converting an existing property to being computed renames the existing property & creates the computed one

11

[quote=83240:@Norman Palardy]Depends on if you create a new computed property (that won’t create an accompanying backing property) where converting an existing property to being computed renames the existing property & creates the computed one
[/quote]

I have seen this bug
 create a property call it MyProperty as sometype. Right-click and select Convert to Computed. Now you have

MyProperty-
-get
-set
MyProperty as sometype

and a " value does not exist" on run with mMyProperty=value hilighted

12

I have seen the same thing as Jim, and it only seems to happen when the property originally starts with an “m.” Of course when I just tried it in a new project I didn’t have any issues.

13

I can repeat this bug consistently. Add a new property. While it is still selected in the navigator, right click it and click convert to computed, hey presto property without the m prefix.

Do the same again, click on another item in the navigator, then click back on your property to select it, right click, select convert to computed, bosh, property prefixed with m.

14

I’m able to replicate it with Mike’s method. If you press cmd-z after creating the computed property with the accompanying property having no m prefix, then the property will gain the m, indicating it is something the IDE is messing up directly after the computed property is created.

Edit - To add what Mike said, the name field, type field, or default field must have focus when the computed property is created for the bug to occur, it doesn’t have to be newly created as long as one of those fields has focus.

15

[quote=83268:@Jason King]
Edit - To add what Mike said, the name field, type field, or default field must have focus when the computed property is created for the bug to occur, it doesn’t have to be newly created as long as one of those fields has focus.[/quote]

Yep that does it here too.