Nasty Flex bugs

[vbajock]

As Chadt would say: "these features are by design":

If you have a Flex session open, and you click on the Screen Designer button, you get a message asking you if you want to save your code. You say yes, then you get an error "vbaConnect, Save Failed" and guess what, you just got screwed: all the code back to your last save is gone. This happens on any computer running PSQL, the Screen Designer and Flex when you try to bounce back and forth between Flex and the designer. If you don't manually save before switching to designer, you lose.

Also, if you put in a push button whose sole job is to shell to another app, on some screens it will give the app the focus, while on others, it always returns the focus to Macola, hiding the shelled app from the user behind the Macola screens. This one pisses me off, because Flex is so buggy most of the time all I want to do is shell out of Macola to a decent development enviro. Any work arounds or experience on this one would be appreciated. I've tried various Appactivate and Shell premutations, to no avail.

 

[abaldwin]

vbajock,

Just so I can beat Chadt to it....."These are wonderful FEATURES!!!!"

I have to say though that I have not run into the shell not having focus. Can you give me an example of this one?

The vbaconnect failing with the ominous message that "You can not save while it is running thing really pisses me off some times. I found a work around that has become second nature for me.

I keep text pad open in the back ground and before switching screens (even modules inside the flex editor) I CTRL+A, CTRL+C and paste it to text pad.

Notice that I call it a Flex editor. Sometimes I even question the validity of calling it a development environment. In all reality the drawbacks to the flex editor are purposely set because it was Macola's decision on how much of and how to implement VBA.

Just my Friday $.02

Andy

Andy Baldwin

 

[vbajock]

The shell problem seems to have fixed itself. I came in this morning, clicked the button, and everything worked perfect. Yesterday it drove me nuts. I hate it when I have no explanation for something - I know when I distribute the app it will come back to haunt me.

I haven't gone so far as to keep a notepad open as you suggested, but I might start

 

[abaldwin]

Can you past your shell call here for me. There is a switch that is suppose to make shell be forward and have focus. Would like your call so I can see if this is reproducable in my system.

Andy

Andy Baldwin

 

[vbajock]

Elsewhere in the app it sets this value from a parameter screen:

oVBNetProg=sUserPath+"ColorCodes.exe"

This pops the app:
retval = Shell(oVBNetProg, 1)

 

[chadt]

ok.....im really upset you guy beat me to the feature comment in macola.....anyways.

if your calling a app you developed.....why don't you force it to have focus when the app starts instead of counting on flex to do it for you......becuase we all know flex is a quality product that you can rely on.

I can't belev=ive someone mentioned the quality VBAConnect that macola developed.....let me tell you....that is one stable piece of code.

 

[abaldwin]

The "1" should do the trick. I have found though that at least twice today I could not get it to run if I had the Flex editor open whether I was stepping through code or not.

i.e. Had the flex editor open. Ran the button from the screen and the outside app opened and went behind macola.

Closed the editor. Re-ran the button and the app worked fine.

Anyway....glad it works for you now.

Andy

Andy Baldwin

 

[vbajock]

Your right - having the editor open is what causes it. That's great to know because it won't affect my distributed app. Chad, I tried everything to force it but something in Flex is hanging out there and always seems to force macola to the front. Since this is only happening in development, I am not going to put any more effort into it.

Here's another bug- Item Master maintenance:

macForm.UserDefined.Text always returns "", no matter what the value is in the User Defined Code box. I can't find any other macform field that would refer to this value. I ended up having to write a bunch of code to retrieve the value from the db. I am wondering if this is going to be a recurring problem.

 

[abaldwin]

I dont seem to have the userdefined field on my form.

I have usercode and the text property seems to return fine.

Thanks

Andy

Andy Baldwin

 

[vbajock]

Must be a version difference - I don't have Usercode. This is a PSQL client. Are you looking at MSSQL?

 

[abaldwin]

Yea, I am looking at the MS-SQL version. I can look at the P.SQL version this evening.

Andy

Andy Baldwin

 

[Rob7]

The usercode field is an open-for-any-use field that has a text box in designer that you can unhide. There is a direct connection between these. The user_def_cd_1 thru 5 are just open fields in the database that have no direct conection between them and any form level object. You would have to write a bunch of code to get this information out. This is the case in both the PSQL and MSSQL versions as far as I know and I have a couple of clients using this usercode field.

Rob

Cytec Corporation
rbrown@cyteccorp.com

 

[vbajock]

Rob, The two character user-defined code on the Item Master Maintenance screen is the field I am trying to retrieve data from. I don't seem to have a macform field object for this field. The closest I have is macform.UserDefined. If I refer the macform.UserDefined field, it always returns null. Alex has macform.UserCode, which I don't have and it returns the correct value. He is on MSSQL and I am working on a PSQL client.

 

[Rob7]

My bad. I was thinking of user amounts. I looked and I have UserCode in macForm on both MSSQL and P.SQL Versions of Macola. This is very strange. I have never heard of having some objects but not others. The only thing I can think of is to check to make sure that you have the following checked in References:
Visual Basic for Applications
vbaConnect
OLE Automation
VBAConnectEx

If all of that is checked, you might want to reinstall Flex.

Rob

Cytec Corporation
rbrown@cyteccorp.com

 

[vbajock]

Rob, you are really helping me out just by letting me know that I should have a macform.Usercode on PSQL. I'll start trying to figure out why it's not showing up.

 

[Rob7]

I looked on the Macola knowledge base and did not find any entries for this particular problem. Do you have access to Macola tech help? That is the only other thing I can think of.

Rob

Cytec Corporation
rbrown@cyteccorp.com

 

[stravis]

In regards to the postings on the MacForm.UserDefined and MacForm.UserCode controls I think I may have an answer.

The MacForm.UserDefined control is a Macola Push Button. This button is hidden by default and is used to open the User Defined Fields Dialog. The Text property is returning a blank value because the UserDefined push button is hidden on your form, and all push buttons that are hidden on a Macola screenset return a blank value from the Text property when requested from within Flex.

The MacForm.UserCode control may be missing because of a couple of different reasons. First, it may be called something different on your Macola screenset. If the literal "User Code", on your Macola screenset, has changed to something different then that change will be reflected in the VBA editor as well. Second, if you are running on an older version of Macola and at the time of the creation of your VBA project the screenset literal was something different than "User Code", but now is set back to "User Code" then the VBA editor will only show the original naming convention for the control. I'm not sure how far back you have to go in order to still receive this problem, but I know it is pre 7.6.100.

There are a variety of ways to "fix" the aforementioned problem, but I will only discuss one of them in detail here. The solution to finding what Flex is calling any Text Box, Button, Check Box, etc.. is the following:

1. Open the Macola application that uses the screenset you wish to find the VBA control name for.
2. Launch the VBA IDE from the toolbar or the File Menu.
3. Holding down the SHIFT key right-click in the white space of the control you are searching for the VBA control name for (in this case you would Shift+Right-Click on the User Code field).
4. Watch as the VBA Editor opens up to the default event for the specific control you Shift+Right-Clicked on.

Other solutions include: changing the name of the literal back to "User Code" and, if the literal is correct but your VBA is incorrect, export all your code (make sure you get any nested projects), backup and delete your VBA project, and then finally create a new project and import all your existing code.

I hope this works for you.
Scott Travis