Creating new form from existing form (1 Viewer)

[arnelgp]

i remove the Load cursor/Set cursor.
instead add a Transparent button overlaying on the two textbox.

 

[Dave E]

Although I got rid of the setcursor and loadcursor API calls for testing, I still crashed, although less often. I would try removing all API code and see if that helps. This version posted by @arnelgp for me is even more unstable then previous versions. This crashes when I simply close the form. So I really think the culprit is API.

Hi MajP,

I 'commented out' all references to LoadCursor and SetCursor from the form (the only only that calls the LoadCursor action) and the function in Module1, compacted and compiled it, but the problem persists. The trouble is that the issues happen at, what seems to be, random moments although it is more likely to happen as soon as the form is opened and then Design View clicked soon after.
Although I was optimistic about API, I'm not so sure now.

DaveE

i don't see any problem with MainForm?
btw i change it to pop-up (centered).

The main form - MainOptions, already had pop-up set and centred, together with fill screen etc...

 

[Dave E]

i remove the Load cursor/Set cursor.
instead add a Transparent button overlaying on the two textbox.

I commented out the Load/SetCursor and compacted and compile to no avail - the same issue persists. It is not a consistent bug and, just when you think you've found the problem, it screws you up...

Could you explain the second part of your post about using a transparent button on, presumably, the LatinName and CommonName test fields on the PlantList subform?

DaveE

 

[arnelgp]

on design view, click on PlantList subform.
On Property Sheet you will see there are 2 command buttons (cmdLatin, cmdCommon).
these command buttons are "in-front" of those two fields. so you think you are clicking on
the field, but what you are clicking is the button. the buttons Back Style is Transparent.
and the Cursor On Hover property is set to Hyperlink band.

 

[Dave E]

on design view, click on PlantList subform.
On Property Sheet you will see there are 2 command buttons (cmdLatin, cmdCommon).
these command buttons are "in-front" of those two fields. so you think you are clicking on
the field, but what you are clicking is the button. the buttons Back Style is Transparent.
and the Cursor On Hover property is set to Hyperlink band.

Hi arnelgp,

I see that, but it didn't stop the issues.
Thanks for trying though.

DaveE

 

[Dave E]

on design view, click on PlantList subform.
On Property Sheet you will see there are 2 command buttons (cmdLatin, cmdCommon).
these command buttons are "in-front" of those two fields. so you think you are clicking on
the field, but what you are clicking is the button. the buttons Back Style is Transparent.
and the Cursor On Hover property is set to Hyperlink band.

Hi arnelgp, No change, I'm afraid.

The problems is on MainOptions. That was my fault I wrote MainView. I corrected it.


1. Open the MainView.
2. There is a plantlist subform on the left. Take your mouse and move it in the subform. This brings up the finger pointer.
3. Switch to design view
4. If it does not crash. Close the db and it will be locked.

MajP,

I tried that too without any success. This is real challenge...

 

[MajP]

I tried that too without any success

Sorry that was not meant to be a fix, that was supposed to describe how to recreate the problem. I was pretty confident that it was the API call since if I did not move over the subform and went directly to design view it would not crash but crashed every time I hovered over the subform.
I do not think this is traditional corruption. I do not think a compact and repair, or a decompile will fix this. This form is complex. Did you save to and load from text all subforms as well as the mainform? If it is not the API then I think it is actually in the design and Access just does not like it. I am thinking this is a bug and not corruption. I will dig into it.
I have had problems like this with a TreeView control. If you did a certain step in design view it would fail and never recover again. It would always require starting with a clean control and rebuilding in the correct order.

 

[MajP]

I am baffled.
I did everything I could think of. Maybe someone else can look.
1. Removed all API code
2. Saved all objects to text
3. Created new database
4. Imported tables
5. Compact and Repaired
6. Read from text all objects

That is about as clean as could be. I looked at that remaining code and nothing popped. You do have some recordset looping in the form open and current events. I did not dig to far into that, but if it is the code it has to be something in an event like a mouse move, form open, or current. It is something that is happening automatically without a user interaction (not a click event or data update).

Attached is the built from scratch "clean" database but still the same problem.

 

[Dave E]

I am grateful for the time you've spent on this problem but I think, like me, you like a challenge.
I worked on the database last night without a single issue. It was a pleasure to be able to do that, but that only means I've been lucky.
I will continue to develop the database and look out for any more problems.

As far as I can tell, I have restored the db to the state before I submitted it, i.e. API working and code as original.

If it re-occurs then I will think about changing the MainOptions form design to simplify its operation.

In the meantime - thanks again for your input and time. And Pat's.

DaveE

 

[arnelgp]

i delete the autoexec macro where MainOptions form is being opened.
instead i use it as the Startup form.
i haven't encounter any crashing since.
for you to test.

 

[MajP]

@Dave E and @arnelgp,
I tested @arnelgp version and it seems to be stable. If the only difference is the Autoexec then I am even more baffled why that is. I have never heard of any autoexec issues.

 

[Dave E]

Hi MajP,

I deleted the Autoexec and opened the form from the Forms List. I don't think it's an Autoexec problem.

I will start to look at how to resolve the problem while retaining the functionality of the MainOptions form.
That could be a nice winter project.

Dave E

 

[MajP]

Hi MajP,
I deleted the Autoexec and opened the form from the Forms List. I don't think it's an Autoexec problem.
I will start to look at how to resolve the problem while retaining the functionality of the MainOptions form.

Was that last version stable for you? If so then you probably can readd the pointer code. If it is fixed I have no idea why.

 

[Dave E]

Was that last version stable for you? If so then you probably can readd the pointer code. If it is fixed I have no idea why.

The version from arnelgp seems to be OK. I have been using it normally with no failures.
Last night, I started to gradually remove some of the changes arnelgp made to see which may have made a difference. Still functioning well.

I will post a fuller report toarnelgp shortly.

Thanks for your help. It has been constructive.

Dave E

 

[Dave E]

i delete the autoexec macro where MainOptions form is being opened.
instead i use it as the Startup form.
i haven't encounter any crashing since.
for you to test.

Hi arnelgp,

The good news is that I have had no further problems with the database.

I took the modified db from you and -

Removed all of Module 2, reverted to OpenForm (Maximise) with all previous property settings for the form.
Added back all the tables, forms, queries and reports that I removed prior to posting it to the forum.
Left the startup for MainOptions as you demonstrated.
Left the mods to the PlantList subform - it seemed better than my version.

I still have no idea about the cause of the problem but I'm grateful to have the database working in a way that doesn't make me cringe every time I steer the cursor towards the Design View option.

Thanks for all your help. I would describe your help as cool, calm, polite and professional.

Kind Regards

Dave E