I’ve got a Button with the caption of “USER NAME” that gets its caption changed and then clicked by a sendmessage api from another app. This works fine, it changes the caption and shows a msgbox message that it was clicked and shows its name. The problem I’m having is that even though the caption was changed by the other app (now says “JOE”) it does not seem to have changed. VIsually the caption now says “JOE” but in the message I am showing the caption and it still says “USER NAME”. I have a refresh before showing the message but that doesn’t seem to help. Below is just the message that shows it is clicked and the caption but has not changed even though it looks like it has. This is a windows app. Any help would be appreciated, thanks.
Maybe a race condition? The method is entered before the change has happened? After all, online stuff needs time.
Try (untested):
Make a custom button class myButton.
Add a property CaptionText as String
Set the btnWagerName to class myButton
Let the sendmessage Api change CaptionText instead of Caption
Before the msgBox write me.Caption = me.CaptionText
I change the caption with an api call. Below is how I do it from the other app. I change the caption and then click the button twice because sometimes the button loses focus and doesn’t click if I only click it once.
Using SendMessage with WM_SETTEXT doesn’t update the properties in the Xojo framework (or, at least, it didn’t used to and probably shouldn’t), it just changes the displayed text of the button object.
I’m not sure why you’re doing it this way, but if you’ve written both applications then you should be looking at an IPCSocket to perform operations rather than manipulating the window with the Win32 API.
Thanks Markus W. I don’t think it’s a timing issue. After the other program sends the message and changes the caption I’ve waited for 30 seconds and clicked the button and it still says caption is “USER NAME” even though it visibly says “JOE” on the button.
Thanks Anthony. I have written both applications, just for my personal use, not for distribution. One program (lets call it the “frontend”) selects the user and then finds the window of one of multiple apps by the app name, then finds the button in that app and renames it. This is the way I did it in .Net as I created the frontend app after I created the others when I realized I needed a way to jump to the different apps. I don’t have experience with the IPCSocket but maybe that is the way to go.
So you may have several applications waiting for such changes? If they are running at the same time, an IPCSocket will be more complex (basically, one socket between each app).
I’ve no doubt your technique is right for such simple things (although, as a Mac guy, I don’t know this messaging system much; I think it’s like AppleEvents).
I’d say Xojo has a bug of not handling (or, at least, noticing) those messages: if the object changes by other means than right inside the language, it obviously becomes out of sync between the OS and the language.
The solution would be to fill a bug report about Xojo not handling or knowing about these messages and waiting for it to be changed; in the meantime, perhaps shared memory would do the trick?
as Anthony mentioned i think xojo have intern properties and the native os components have its own properties which are not reflected if you change them via api call.
Yes, correct it could be waiting to connect to as much as 5 different apps at one time. My workaround was to have the frontend write to a textfile with the new name (“JOE”) and then have the send message click the button and have the button open the textfile and get the name. It’s a kludge but sounds a little similar to the socket way of doing it having a file pass the data between the two apps.
could you try to register for a windows message in xojo and then call a method that change the button + do the action. i used windows api only in vb6 not in xojo.
He could use Win32 subclassing to listen for the window messages coming in and store the value himself, but this was really just the wrong way to build interprocess communication when you control both ends. The Text file way isn’t…awful.
It’s not a bug, Xojo just doesn’t listen for that change and update the internal properties because…well, why would they? It’s a button, not a text field.
So either these Windows message are poorly implemented (e.g. should trigger an error when the receiver doesn’t listen) or I don’t agree that Xojo shouldn’t listen to an OS mechanism.
While I’m not sure what is the extend of these messages, I can fairly imagine a Xojo app’s state being awful just because these messages are “semi-ignored”.
John’s case is a proof of this: a message, well defined, known and supported by the OS produces an out-of-sync between the OS state and the “framework” state.
And, not just text fields have a text property; I don’t quite understand your last phrase.
What I’m saying is that it’s wrong to expect the change to be reflected in the framework. I’d argue that .NET/VB6 shouldn’t do this either – for a number of reasons – if it actually does.
A button is an action initiator, not a data supplier. The value of the text displayed in a button should have no bearing on its functionality, while the text within a textfield is a primary means of data supply thus properly receives and processes this particular message.
I’d tend to agree with you, which would mean the Windows messaging system shouldn’t be able to mess with UI things. So it’s “poorly implemented”.
Well, adjusting a button’s caption has nothing to do with foolishness (though I’ve not managed to find one occurrence right now). Even the Apple’s HIG mention this is possible (IIRC), because, for example, when a criterion on a dialog changes, a push button may have a leading ellipsis added or removed (if an additional dialogs would appear next).
Changing the text of a button doesn’t mean its functionality actually changes.
Another example: say you have a dialog window with a listbox where the user can add and remove items. The push button would handle these items. The button’s caption could read “Handle “+str(MyList.ListCount)+” item(s)"; the button caption would be contextual, the behaviour wouldn’t change, and that’s not an idiocy.
I would disagree. A RUN or START button becomes a STOP or ABORT button while running a lengthy analysis. Sure, you could use a second button, but that is less elegant.
real interprocess communication i used only once in vb6 and it was very cool.
i think in xojo you can choose file,network or win api. throw a dice
i would try a broadcast message via network and client fetch his information.
i guess this IPCSocket class from xojo did not fit together with a ms .net app.
