eVB quirks?

For the program that I'm writing, I've integrated "save as" and "open" common dialogue boxes. These work just fine on my CE6 ARM device, but when I run the exact same .vb on my CE5 x86 device, the following happens:

The "open file" dialogue fails to return any value, so when I select a file, exactly nothing happens. When I put my routine to fetch the file name through the "open" dialogue into a MsgBox(), nothing happens, the message box never appears.
When I try to save a file, it lets me choose a filename and try to save just fine, it just never writes anything to my disk.

Keep in mind that no error messages ever appear, and that everything works fine on my other device.

I've worked around the issue by just having the user input file names via an input box.

Does anyone know what could be causing this?

Not too sure, but do x86 and ARM have different implementation of common dialog box?
Did you target the compiled eVB to x86 or did you just run it (the .vb file)? Maybe that's the difference.

Was it that there was a separate program to compile it to CAB? Not sure, I didn't use eVB for a long time. I remember there was like a CAB builder sort of thing.

Just my two cents.

-stingraze

Edited by stingraze 2024-01-18 4:21 AM

As alluded to in the event thread, are you developing your app with Option Explicit enabled in the project settings?

Yeah, I do have Option Explicit enabled

I'm just running the final .vb file directly, you only ever have to make a .cab if you want to package the eVB runtime with your file (which I don't)

So presumably you have something like:


If you run the above msgbox code, presumably you get
Null: False, Empty: true, Length: 0, Is NS: false?

What is the value of the second msgbox if that is legal?

Huh

I got the common dialog box, entered "test", and then it crashed

Edited by I dunk for bananas 2024-01-18 1:48 PM






Attachments
----------------
crash.jpg (33KB - 0 downloads)

That's an access violation, how odd. It may not know what vbNullString is, you could take that out (I can't remember the legal syntax vs. VBA/VBS any more).

Is this legal:

This works fine, I get the dialogue box, type in "test" and click "ok", and then I get a message box with no contents

Dim strResult as Integer?

Same result!

I expected that to crash or return an integer to signify the pressing of either OK or CANCEL. If you run my sample from my post 3 posts ago (I was editing it when you replied) on your ARM device, do they cooperate with values on that (replace vbNullString with "" if it doesn't like vbNullString)

If I run that on the ARM device, enter "test" again and click okay, I get "Null: False, Empty: False, Length: 22, Is NS: False" (followed by a blank MsgBox)

Edited by I dunk for bananas 2024-01-18 2:05 PM

okay, so CE doesn't return an error value from ShowSave (may be it does from ShowDialog).

I wonder if it's callable from a DLL import?

Looking at the x86 MSCECOMDLG.DLL the function *appears* to be implemented and not stubbed. Can you try un-registering and re-registering MSCECOMDLG.DLL?

Sure! I unregistered it, ran your code again (just to see what would happen), and it behaved exactly the same. Then registering it again and running yet again only yields the same result, again
Wouldn't it be expected for common dialogues to stop working if I unregister the corresponding DLL..?