Solved Return without GoSub error (1 Viewer)

[asteropi]

Hey all
So I have an OrderF form with a subform inside for order details. I have made a combo drop down menu here to show me my products.
The combo box is taken from a query with only one table.

When I go to create a new record, I put the customer's data, but when I go to choose the products in the order details I get this "Return without GoSub" error. It's the first time I encounter such a thing and I searched the forum but nothing seems to match my case.

I tried a compact and repair but it didn't work. Please shed some light here. I don't know what's wrong

 

[MajP]

Is there any code or macros with that control? If so post
Any code or data in the forms before update event or on current event? If so post

I am working with a Russian on their database, and if any form controls use Non-Latin alphabet for naming of the control a lot of problems arise. We had to change names of controls (especially those used in code) to Latin alphabet.

 

[NauticalGent]

We would need to see the code behind this form to evaluate...

 

[asteropi]

The first one is to update the partial sum and the second one is to refresh the quantity

I recreated the form and took it step by step. Tha main form works fine, it's the subform that has the problem. As soon as I input the subform and try to run it I get that error

 

[The_Doc_Man]

Usually, a "Return without GoSub" error is caused by something else being unbalanced in the same module. It is hard to say exactly what is wrong but it is something like an IF without an End If or a Do without a Loop at the end or anything that establishes a block context. As to what specifically does this? You can find out by letting the debugger stop you in that module. Now slowly read code upwards (towards the beginning of the module) to verify integrity of all block-establishing items, because your failure to properly identify the end of the implied block structure encloses the GoSub that would match the Return that bombed out on you. The first GoSub you find is probably the one that is hosed up by being enclosed within the next block-establishing syntax element above it.

To be clear:

IF X THEN
.....  this is inside a block
END IF

FOR EACH ctl IN ME.CONTROLS
..... this is inside a block
NEXT ctl

WHILE X < Y
..... this is inside a block
NEXT

Other things can create implied blocks, but these should give you the idea. And when a block is left unsatisfied, what follows it gets "eaten" and thus leads to this kind of error.

 

[MajP]

In my experience any names with non-latin characters is problematic. I believe this error is due to that and not anything to do with GoSub which is not relevant here.

I would change every control name to Latin characters.
I will not even try to debug a database that uses non-Latin characters in the names. It will not work correctly in an English version of access.

See my recent thread

Problem "With Communicating with OLE Server" Using Non-Latin Alphabet Databases

I kind of stop helping people on this site that post databases not developed in a Latin alphabet based database (examples Arabic, Cyrillic), because I run into too many problems that cannot be fixed without a rebuild from scratch. The problem I see often is this message when I try to modify...

www.access-programmers.co.uk

 

[asteropi]

Usually, a "Return without GoSub" error is caused by something else being unbalanced in the same module. It is hard to say exactly what is wrong but it is something like an IF without an End If or a Do without a Loop at the end or anything that establishes a block context. As to what specifically does this? You can find out by letting the debugger stop you in that module. Now slowly read code upwards (towards the beginning of the module) to verify integrity of all block-establishing items, because your failure to properly identify the end of the implied block structure encloses the GoSub that would match the Return that bombed out on you. The first GoSub you find is probably the one that is hosed up by being enclosed within the next block-establishing syntax element above it.

To be clear:

IF X THEN
.....  this is inside a block
END IF

FOR EACH ctl IN ME.CONTROLS
..... this is inside a block
NEXT ctl

WHILE X < Y
..... this is inside a block
NEXT

Other things can create implied blocks, but these should give you the idea. And when a block is left unsatisfied, what follows it gets "eaten" and thus leads to this kind of error.

Thank you. This seems to have worked for now