PH Gmap - Google maps, Street View, Routes, GPX & more

[lp]

Judging by the opcodes in the illegal aes error messages I'd assume it relies on WDialog which is often the case of software written for magic. I probably have ndialog installed, but if I recall correctly it didn't replace wdialog 100%. Situation is just the opposite here, I used to have xaaes installed, but since ozk left the project it goes in a direction I don't agree with. So to be fair, its more of a design issue than a bug. If you don't want to solve it, just add "requires xaaes" to your websites list of requirements. I can accept that it just don't work with naes 2.0. I would also say never assume certain things are not used. There are still die hard single-tos users to this day, etc.

[wongck]

Oh, I will fix it, both of us already spotted the issue with it, so fixing will be very simple now.
Also there already so few newer software around for our computers.

Just that I need to find N_AES and install it onto my system and probably over the weekend or sooner.
I would also like to try out again the N.AES 2,0 that I did not try previously. Alway good to re-discover old software.

[jfl]

Just that I need to find N_AES and install it onto my system and probably over the weekend or sooner.
I would also like to try out again the N.AES 2,0 that I did not try previously. Alway good to re-discover old software.

I may still have the install disks at home. I'll check that tonight.

[wongck]

How does it reports the AES errors ?
to the toswin window?

[wongck]

Did you use PH Gmap v2.1 ?
I got a map instead of a grey window in the main window. I can't duplicate the main window being grey.
Of course the other windows are blank.

Now I know why i was using wdialog extension now, using it I did not have to fill in the clipping rectangle... so was just being lazy.

[wongck]

I have to replace the list boxes as those are reporting errors.

Do you have any development notes for N.AES ?

[lp]

For list boxes you should be able to use http://toshyp.atari.org/en/00800f.html#menu_popup

[wongck]

For list boxes you should be able to use http://toshyp.atari.org/en/00800f.html#menu_popup

yes, that would what will be using.

[lp]

I have to replace the list boxes as those are reporting errors.

Do you have any development notes for N.AES ?

The only documentation I am aware of is in the NAES hyp included with NAES itself. Also TOSHYP where it notes certain AES calls as NAES only.

[wongck]

Ok, I did not expand the hypertext docs on the archive. Will do that and see if anything helps.

[wongck]

It's fixed now.
Because I changed the RSC, the German RSC is now buggered.
So that's needs fixing, I wonder if I can just resort that tree only.
I still need to update the docs.

So will get it up on my site in a day or two.

[wongck]

Well, it's fixed and I placed it on my google sites.
But now Google have suspended that site, for no reasons.
So until Google unsuspend it....

[lp]

Is it me or odd coincidence you update an app that uses a google service (maps) and suddenly everything halts. Hopefully it's some misunderstanding.

[wongck]

It is unsuspended now and accessible, so please try it and let me know if it is working on your system.
https://sites.google.com/site/probehous ... O1-PH-GMAP

Not sure what's the issue was with the suspension, it was suspended without any warning. A quick Google on the topic reveals that it is a bot that scans the activities on their system, and my guess is that they tighten the rules with the advent of the new administration (look at all the FAKE news about it ).

I doubled checked my emails for any mails from Google about it, but none. So as mysteriously as it was for both suspending and unsuspending reasons. So no way of avoiding it as I do not know what's the reason. May be too many talks about their new US administration.

[wongck]

Is it me or odd coincidence you update an app that uses a google service (maps) and suddenly everything halts. Hopefully it's some misunderstanding.

Could be, may be they need to check out a 800KB package uploaded to their server. May be stuff about hacking CIA or Walmart.
Just to be sure it isn't.

[lp]

It seems to work ok now. One small visual issue. The call to menu_register() really should use a string beginning with 2 spaces. If I hide and unhide the app it destroys it's own menu entry name. Also the check mark when it's topped appears over top the name. I'm referring to the drop-down menu that lists all the running apps.

[wongck]

Thanks Lonny, will fix that as well.

[wongck]

Oh that string is inside the RSC, so that was an easy fix.

I start to fix the other prgs.

[lp]

Some more minor gmap issues you might want to care about.

First time I start the app, go to enter an address, the cursor is out of focus, nor do I see a cursor. I have to click the edit field to get it to register my key strokes. Later on if I go back to enter a new address, previous address appears, but no cursor. Start typing, cursor appears but leaves ghost image of itself. Visually it looks a little messed up.

Double-click a location on main window, yields street view window. This window appears partially under the menu bar, messing up the window title.

Favorites window, if popup is empty it draws some thin object that it probably shouldn't.

[wongck]

Thanks for reporting.
Yes, I saw most of the items reported and is fixable except the edit field stuff.
For the edit field, I do not know how to set focus on it as it is not the standard form_do call.
I need to research that. Others are simple to fix.

All these are GUI related.
This now ups my thinking of 80% of programming on an Atari application are due to GUI to around 90%.

[lp]

I had a lot of trouble with this myself. Looked in my own sources and I used objc_edit() to manage the cursor inside my redraw routine. Maybe that helps you look in the right direction. Indeed the GUI becomes a project in itself.

[wongck]

Yes, I am using objc_edit to draw the cursor.... and I found that I had a window redraw after that was set, and so erasing the cursor (silly me). So that's fixed.

Only issue now is the focus, I cannot see the focus on nAES but on XaAES there is a thin red perimeter on the object.

[lp]

N.AES does not have a focus indicator like that, simply the line with the cursor is the one with focus.

[lp]

Not a bug per say, just a visual oddity. The popup that appears when right clicking, the border color of the popup inverts with the item highlighted. Depending on ones color scheme this looks unusual. Maybe you are using custom popup code here, I never seen this with aes popup calls.

Perhaps some tips on cursor placement. The way I handle it is this. Each window has a structure, one item in this structure is the default edit field (object number) where the cursor should be placed whenever the dialog opens. If the dialog has no edit fields I set it to -1 to skip the cursor rendering calls. This also signals the redraw code to avoid cursor redraws for a given dialog.

There's also another item in the field, currently edited object number, and this is used during redraws so the cursor is maintained at the correct edit field.

[wongck]

Thanks for the hints.
Yes, right clicks or any button will call the popup.
Cursor been fixed and yes, redraws are specific to each windows.

I am now struggling with a different issue.
A small percentage of the time, the streetview window crashes on 1st invoke.
This only happens in nAES, and on 1st invoke. Subsequent close & open does not crash.
XaAES does not exhibit this.

I tried GDB, but something weirder happened.
Without optimisation so that I can see the code, the location on map is totally misaligned ( several streets away) from the double click.
When I put back the optimisation, it spot on the map. So optimised and unoptimised code behaving differently ??
This is beyond me, so GCC gurus is needed here.

I may need to go back to old fashion printf statements.