Announcement

Collapse
No announcement yet.

JK-IDE Version 2.0 including Visual Designer V 1.0

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Jim Fritts
    replied
    Juergen Thanks for the quick response,

    Yes, centered on the IDE would be ideal.
    Yes, the different scope buttons are nice for those that can guaranty that what is being replaced is correct (hint: those that live in a perfect world ha ha). Due to similar value spellings I have to validate each change. That is why I don't use the scope buttons all that much. Old school I guess.
    Thanks

    Note:
    The apps I design usually drop a message box / option box at the center of the app or use a text message area on the app to notify the user what is happening. I consider that as courteous to the user. My system is typically just one small display so it's really not that big of a deal; however, I would think those that have much larger screens may feel some pain. I'm just saying...

    Aw the escape button... you're trying to get me to do more work aren't you?

    Leave a comment:


  • Juergen Kuehlwein
    replied
    Hi Jim,


    why would you want to do Find and Replace one by one? There are three buttons at the bottom of the dialog offering different scopes for this operation. The leftmost button lets you define the scope by a selection, so if you want Find and Replace to occur only in a specific area, select it and use this button - all occurences of "find what" will be replaced by "replace with" in one go.

    The more, the second dialog is in fact a messagebox, you could use the keyboard for handling it too.


    In general Windows centers messageboxes on the screen, but of course, i could make IDE related messageboxes appear centered on the IDE - this seems to make sense. Let me know, if you still want it centered on the IDE.


    JK

    Leave a comment:


  • Jim Fritts
    replied
    Juergen Hi,
    No problems to report. Thank you for your hard work.
    I just have an annoyance I've been meaning to run by you. As usual I've been doing Find and Replace quite a bit and would like to cut down on my mouse movement to perform that tedious task. I use the JK-IDE at the side of my screen and it would be nice if I didn't have to move my mouse so much. The Replace Dialog saying "No more matches found. Continue searching from the top? Yes No Cancel" only appears at the center of the screen. It would save me a whole lot of time if that dialog was centered on JK-IDE.
    Another method would be to add the functionality to the current Find and Replace Dialog and remove the Replace dialog altogether. Just an Idea. Thanks
    Click image for larger version

Name:	Replace.jpg
Views:	155
Size:	39.1 KB
ID:	774650

    Leave a comment:


  • Juergen Kuehlwein
    replied
    Hi all,


    V 2.3.0.10 is online - adds a context menu to file tabs, fixes a few issues reported by various users, almost all features now support code inside the (implicit) Main function in FreeBASIC (all code outside procedures), a debugger is under construction. PLEASE DON´T USE THE DEBUG MENU in FreeBASIC, because currently this is likely to crash the IDE.


    JK

    Leave a comment:


  • Jerry Wilson
    replied
    Thanks for getting back to me. For development, I need to run the compiled exe in a specific directory (different from source code) but have a workaround to do that - which works fine.

    Within the app, I do use EXE.Path$ to determine the current path (you know that I'm trying to clean up legacy syntax in my code). But, I hadn't considered the potential problems with CURDUR$ that you mentioned. Thanks for the advice.

    Leave a comment:


  • Juergen Kuehlwein
    replied
    Hi Jerry,

    in fact currently the IDE doesn´t set the current directory for an .exe it runs. It implements the "SHELL" command, which sets the actual current dirctory as new current directory for the new process it starts. That is, in your case the current directory is not the path of your .exe!

    I could change that, so that the current directory defaults to the .exe´s path.

    On the other side relying on the current directory (CURDIR$) is potentially dangerous, because even if the current directory is process specific, there might be actions inadvertently changing it (among others e.g. Open- or SaveFile Dialog). So in my view you should ALWAYS use exe.path$ for referencing the .exe´s path.


    JK

    Leave a comment:


  • Jerry Wilson
    replied
    I dug around in all of the configuration dialogs and couldn't find a setting either. Perhaps, there may be a switch in a future version (e.g. Run in EXE Path).

    Knowing the current directory is important for the app (location of config files and constructing encryption keys) - and that directory is determined by where the customer installs it. For development, I always know where the compiled app is located so I can just use CHDIR at startup to force that - and pull that line for prod release. Thanks for jogging my memory.

    Leave a comment:


  • Dave Biggs
    replied
    Seems that the IDE is setting the default directory path to the project/source folder - don't know if there is a user option to control that.

    If the current directory is important to your App then maybe you could include something like this in it's source.
    Code:
    If CURDIR$ <> Exe.Path$ THEN CHDIR Exe.Path$

    Leave a comment:


  • Jerry Wilson
    replied
    JK-IDE does compile correctly and place the EXE in the path specified in the #COMPILE directive. So, in this case, the source code is in one directory and the EXE is in another.

    Here's some really simple (and useless) code. In my environment, the source code is in a redirected drive x:\dev\projects\sml. The compiled code is saved ONLY in a local directory c:\dev. I used the PB CURDIR$ function to determine what directory the EXE was started in - which I believe is correct. If I compile and run from the PBCC IDE, CURDIR$ returns c:\dev - which is what I need. if I compile and run from the JK-IDE IDE, then CURDIR$ returns x:\dev\projects\sml.

    HTML Code:
    #COMPILE EXE "c:/dev/MyApp.exe"
    
    FUNCTION PBMAIN AS LONG
      PRINT "CURDIR$ = <" CURDIR$ ">"
      WAITKEY$
    END FUNCTION

    Leave a comment:


  • Dale Yarker
    replied
    From post 107 -
    JK-IDE seems to run the application from the directory where the source code is located.
    If there is no EXE of the compiled program in the source code directory, then it is not being run from there.

    Unless JK-IDE is interpreting the source code itself and not compiling (and not causing the compiler result to run.)

    Leave a comment:


  • Jerry Wilson
    replied
    No. The source code for the project lives on a NAS but I need to run the application on a local drive for testing. I started out using the PBCC IDE which does seem to use the path in the #COMPILE directive as the starting path to run the application in.This isn't a show stopper. I can use a Command Prompt window to start the application or even create a real simple PBWin app with a button. I'm just lazy

    Leave a comment:


  • Dale Yarker
    replied
    Is there a copy of the .exe file in the source code directory?

    Leave a comment:


  • Jerry Wilson
    replied
    I'm probably missing something obvious but does anyone know how to get JK-IDE to run an application in a specific directory? This would be similar to the /D switch in the START command in a Windows Command Prompt window. Even though JK-IDE compiles and correctly places the application in the directory specified by the PB #COMPILE directive, JK-IDE seems to run the application from the directory where the source code is located.

    Leave a comment:


  • Juergen Kuehlwein
    replied
    I´m going to be offline because of a vacation. Please don´t expect an answer to your posts within the next 3 weeks or so.


    JK

    Leave a comment:


  • Juergen Kuehlwein
    replied
    Hi all,


    V 2.3.0.9 is online, this fixes a rare problem with unwanted tab drag mode, when activating the rightmost tab - thanks Jim for reporting and helping to fix it!


    JK

    Leave a comment:


  • Jim Fritts
    replied
    Juergen,

    As yet I have not had any issues since I widened the IDE. The e-mail was sent. It appears the errant behavior happens when the UpDown controls are covering a TAB control and the mouse pointer is leaving or approaching the TAB controls.

    See e-mail for specifics.
    When the .INC file tab is partially covered by the Up/Down control and I click on the TAB for the file I only get a tab down.

    I have validated this behavior many times now. You don't notice it until you get the mouse pointer close to the TAB control again. At that point the mouse pointer changes to [+].


    Note: The described behavior only applies to the last TAB in the TAB control.
    Last edited by Jim Fritts; 15 Jul 2018, 09:42 PM.

    Leave a comment:


  • Juergen Kuehlwein
    replied
    Jim,


    My fist thought when re-testing was: could it be that the WM_LButtondown is passed to the TAB control when clicking a scroll button (an Updown control)? According to Windows standards this shouldn´t be the case, because the Updown control processes this message and therefore should eat it (prevent it from being passed up the parent chain) - but you never know. All i can say, for me this is not the case, WM_LButtondown never reaches the TAB control when a scroll button is clicked.

    Could you please drop me a mail at <jk-ide at t minus dot de> so i can return a special test version for you verifying what happens on your computer.


    JK

    Leave a comment:


  • Jim Fritts
    replied
    It just appears and corresponds to the actual mouse location. I will try uninstalling the mouse. Reinstalled but untested. The actions that I have described above copy cut paste to include files is new to me so I cannot say if the behavior is indicative of this IDE version or all of them. Note of interest is that I can move the mouse pointer away from the IDE and back to the IDE and the mouse pointer will change back to [+] no drag/drop. That is why I think the IDE should enforce a limit to the drag/drop area even if the User is still holding down the mouse button. It just makes good sense to cancel the drag operation based on the mouse location similar to the way the OK to drop is done. After all, we are not dragging and dropping the dialog so if the pointer gets outside the TAB area then the drag operation makes little sense.

    Just tested the reinstalled mouse.

    This time without copy cut paste. I think I see the problem. The .INC TABs are behind the TAB scroll direction buttons so when the TAB scroll left is clicked it appears the click is also going below the TAB scroll button and being received by the .INC TAB as a click and hold on that .INC TAB.

    May need to replace any TABs that populate behind the TAB scroll buttons with a no TAB/ no drag area.

    Note: This is my first experience using the TAB scroll buttons and having more TABs than can fit on the screen. Perhaps this behavior has been lurking in the background all along.

    Aw... I widened the IDE size so the TAB scroll buttons are no long encroaching on the .INC TABs. I'll be testing to see if that makes a difference.

    Leave a comment:


  • Juergen Kuehlwein
    replied
    I'm thinking that [+] should be limited to TAB area only.
    the mouse is captured on WM_LButtondown (inside a tab) followed by a WM_Mousemove exceeding an amount of pixels given by getsystemmetrics(%SM_CXDRAG / %SM_CYDRAG). While the mouse is captured, the mouse pointer shows the current status: cannot drag (the red square), can drag left/right or scroll left/right as long as you hold the left mouse button down. This ends when you release the left mouse button (WM_LButtonup) and the mouse pointer changes back to beam or pointer shape.

    Limiting the drag action to the TAB area, could be annoying, because as soon as you leave the TAB area the action gets cancelled. That means, you must move your mouse very carefully not to coincidentially spoil dragging. I could limit it to a "reasonable" area around the TAB control, but this isn´t standard behavior. Standard behavior is stopping/finishing a drag action by releasing the left mouse button - no matter where.

    Currently i have no explanation for it, and i didn´t change the corresponding code (dragging tabs) for quite some time.

    The [+] no drop pointer is obviously misinformed as to its actual location.
    Does that mean, it jumps, when it appears - or does it still correspond to the actual mouse position. If your mouse is set to be very sensitive (a slight move moves the pointer more pixels than your current drag threshold) you might very easily get into drag mode inadvertently when just activating a tab. If your left mouse button fails to send a WM_Lbuttonup, or if it sends a repeated WM_Lbuttondown because of a malfunction, you get what you describe.

    What about testing with a different mouse ?


    JK

    Leave a comment:


  • Jim Fritts
    replied
    Hey Juergen,

    I use Ctrl V exclusively. I can understand that the [+] would appear on or near the row of tabs but what I am experiencing is seemingly way out of the normal and as yet I have not been able to reproduce it on demand. It has been an oddity. As I said my mouse is rather flaky. These are the steps I have been performing when I notice it happening:
    1. Highlight code to cut.
    2. Ctrl X on .bas file.
    3. Click save file.

    May use Tab arrow to bring .inc into view.

    4. Click on .inc file tab.
    5. Ctrl V on .inc file.
    6. Click save file.

    May use Tab arrow to bring .bas into view.

    7. Click on .bas file tab.

    May use mouse wheel up/down to find the next area I want to cut from .bas or use FindNext dialog.

    8. The [+] no drop pointer shows up on the code window where the ][ bar pointer should be and turns to ][ as soon as I click on the code window.

    Note: I never noticed this behavior in previous versions of the IDE. Very odd. The [+] no drop pointer is obviously misinformed as to its actual location. So yes, to be fair it is an intermittent left mouse button. It usually fails to hold. Not likely the culprit if the [+] pops up in the middle of the screen.

    I'm thinking that [+] should be limited to TAB area only.

    Leave a comment:

Working...
X